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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id C0C68E77180 for ; Tue, 10 Dec 2024 14:13:48 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3FD196B01F3; Tue, 10 Dec 2024 09:13:48 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 3A9C96B01F4; Tue, 10 Dec 2024 09:13:48 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 225C76B01F5; Tue, 10 Dec 2024 09:13:48 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id F24D36B01F3 for ; Tue, 10 Dec 2024 09:13:47 -0500 (EST) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 792DCAE75B for ; Tue, 10 Dec 2024 14:13:47 +0000 (UTC) X-FDA: 82879242222.10.CA02686 Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by imf09.hostedemail.com (Postfix) with ESMTP id D1500140002 for ; Tue, 10 Dec 2024 14:13:30 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=ScFZexYJ; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf09.hostedemail.com: domain of will@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=will@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1733840015; a=rsa-sha256; cv=none; b=EeLc5AXbgiws+RXQ9y4Rl8m5Sikj94v807eZgeoxzgtDSyE+dCTqHQ3bHTApoR1mCVjpR/ FgzHD820XibMGh+FYwIj54YpSjRwWIeQKS9TM39B+j9kaB+yKA6gdJ0DQBjfjnv23Q3K/q WHS23PWKArdZDA7/4tkHzTB/whfxkSs= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=ScFZexYJ; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf09.hostedemail.com: domain of will@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=will@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1733840015; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=dsrmQMiPRNQtLASMnp7wNKwahA5UqK6NJVAux3hx5Cg=; b=VOmL489s2ROs/uAj5S7UTJcJW7GXiJ6XiRYCy4l9R8/Pm6vBBgDk379C1YzhzdZQMdBn6W rh1aEOswfdd9Z8F03vtEbQCtkeS1NtGA0n4266JmJ2L8aRQ2U3/fuhoLmiwIOdFPjWy7fl WVTL84jNsK89rXMBqa9Y7t/1QCimB60= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id AF2B5A415CD; Tue, 10 Dec 2024 14:11:53 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9F2D2C4CED6; Tue, 10 Dec 2024 14:13:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1733840024; bh=p1a7HwVIsBUxDg8oRarlZACVtkKI+wv6CArQotlXVmo=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=ScFZexYJCgt6WvxjNXGB3iIshv5MbK12VwWs0RNL583DU7niUDPigVOfY7yoa3/j7 jGKzBvbGaWkSU7EFm2X0qPfbstIi4iKBDga7bJC0k9DWU3BazppUxr0LWaPMk+xnV+ rlYMQcmCO5VeCUkgLgxianbVXCIVXl65tIL1OWREDwLJpFaM5Stz0HxofjGwGB5X+o yT3RQcemmJywxVjQ8F3OLIiwuAl2qtVRprlycljaqADLvtxXjgH3GeHsbNYgTmVzhb IbJUmrWsLgl+k+bglmuJTHdPdx0mlfARHOzohz16FYOvVOYcmimzSppaIV4dfgGZNK xIaVtrdVHGb7Q== Date: Tue, 10 Dec 2024 14:13:35 +0000 From: Will Deacon To: ankita@nvidia.com Cc: jgg@nvidia.com, maz@kernel.org, oliver.upton@linux.dev, joey.gouly@arm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, catalin.marinas@arm.com, ryan.roberts@arm.com, shahuang@redhat.com, lpieralisi@kernel.org, aniketa@nvidia.com, cjia@nvidia.com, kwankhede@nvidia.com, targupta@nvidia.com, vsethi@nvidia.com, acurrid@nvidia.com, apopple@nvidia.com, jhubbard@nvidia.com, danw@nvidia.com, zhiw@nvidia.com, mochs@nvidia.com, udhoke@nvidia.com, dnigam@nvidia.com, alex.williamson@redhat.com, sebastianene@google.com, coltonlewis@google.com, kevin.tian@intel.com, yi.l.liu@intel.com, ardb@kernel.org, akpm@linux-foundation.org, gshan@redhat.com, linux-mm@kvack.org, kvmarm@lists.linux.dev, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v2 1/1] KVM: arm64: Allow cacheable stage 2 mapping using VMA flags Message-ID: <20241210141334.GD15607@willie-the-truck> References: <20241118131958.4609-1-ankita@nvidia.com> <20241118131958.4609-2-ankita@nvidia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20241118131958.4609-2-ankita@nvidia.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-Rspam-User: X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: D1500140002 X-Stat-Signature: qawqsxipgpbtanz6k7wej9gwipdieyp8 X-HE-Tag: 1733840010-940953 X-HE-Meta: U2FsdGVkX19W37XiMwKG34QeTTrAbBKJjbh3v4ZjNAFy0XQ67zLLqH8cAYwVUwS5tnr017ZStGZ158TzIG+wjLnVlHccgUBm7o1FDE5LSJDnKK4mpdq8ytdItQKXvgyk7e4wxpe+D6ut6rZxkWWDbS8iWmKVr5vrpqWPe+hD3Q0vDMxjCOIjFRsBihSzP7VypHHbeLMQi8ecZD+FoGWZRlEVhlgpLt358rMlRLdd4YciC+TIblpDiyu/IR+/TZY4YT9TH2zrdh80f2lGZOnFDT77/w1uHCG7C+r71hU6yFBQu/nxz1ukrEgbq/oeJb0b49p1C7vsoFSVT9CW3gVbR1msGdUBJoXcZQaqmFfVJ8NeAmBUGkfc7tdy0qSt/eQo09zcuESaAMZ2+cFBi4i0VOF1sXO6KeoOdmNQ9gwcF78rTOAO3iEqIET05bSaaSSXw98khvRnUD0ZDMfiq6H7XY1w1/ZZ04OG3J//+mkRrpDBBkoG7f4ZHN2OuMywCZHFsf1PSAwgkKaaSNG7oqgC8sA+uQmLpXnX7m2ctxAaQCojDxreGU3cg0KRPBitKyzazxCa8jgu4mwgHdLD21YeYHrmUOZxv+06d7s/qrfTO1azWDFakQqdcTERELaMzp32eOiDTds29iMFmEKrJE+JCjv7hnqCtG8I0B7pzM/LYULenoxQmMuRh7Y3zn1CFelJU8T9VnIqzeHXMOvg4ZcfLKVCDvspY8Wv34ELSjGaozU2p7ZIo9/SmoaUxc0Mjdh4Wxumd5hfaaGRvN93xClvVOA3nXZUqMCRPiiY1/mQO+nRjwh+npYA5EX00OIbZIelJMIC5SiqFvZTaVmYYHldBnqwaN99nvpzbDmRve+QrcGUczouKLmESMkLJzHiX/HbdAAfDT6K56vI08UKfgFyceV0CDJGQWdOw+sEaO/6r7EQbEWoSD5Kh71XoVFNJ2JvBbtO+vsyyviWCzttChZ OUPDGoJV A5ziI413pgcUm5Cd7S8xXbxtw2C9BnbG71a54AEMDFJEGAkmfXzq+y6bsgsZOf0h54khC5TiaqRfb4b2FfxLrmB73isH9SAm3zq2vSb7FpNPzjSNVf6bbj7mDdVUcdCgPJ/fSnj/8WeX6EbogkDOc8hzvDqDclqtArLj0Jx743WxWfGbKM9jKZYk6LC2/fcmTckLWVjOG4acrrANDk0nZocuXxf0iZVPpxJuHAU9hWFxDSwMUrBHT+ixWVw== X-Bogosity: Ham, tests=bogofilter, spamicity=0.008427, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Mon, Nov 18, 2024 at 01:19:58PM +0000, ankita@nvidia.com wrote: > From: Ankit Agrawal > > Currently KVM determines if a VMA is pointing at IO memory by checking > pfn_is_map_memory(). However, the MM already gives us a way to tell what > kind of memory it is by inspecting the VMA. > > This patch solves the problems where it is possible for the kernel to > have VMAs pointing at cachable memory without causing > pfn_is_map_memory() to be true, eg DAX memremap cases and CXL/pre-CXL > devices. This memory is now properly marked as cachable in KVM. > > The pfn_is_map_memory() is restrictive and allows only for the memory > that is added to the kernel to be marked as cacheable. In most cases > the code needs to know if there is a struct page, or if the memory is > in the kernel map and pfn_valid() is an appropriate API for this. > Extend the umbrella with pfn_valid() to include memory with no struct > pages for consideration to be mapped cacheable in stage 2. A !pfn_valid() > implies that the memory is unsafe to be mapped as cacheable. > > Moreover take account of the mapping type in the VMA to make a decision > on the mapping. The VMA's pgprot is tested to determine the memory type > with the following mapping: > pgprot_noncached MT_DEVICE_nGnRnE device (or Normal_NC) > pgprot_writecombine MT_NORMAL_NC device (or Normal_NC) > pgprot_device MT_DEVICE_nGnRE device (or Normal_NC) > pgprot_tagged MT_NORMAL_TAGGED RAM / Normal > - MT_NORMAL RAM / Normal > > Also take care of the following two cases that prevents the memory to > be safely mapped as cacheable: > 1. The VMA pgprot have VM_IO set alongwith MT_NORMAL or > MT_NORMAL_TAGGED. Although unexpected and wrong, presence of such > configuration cannot be ruled out. > 2. Configurations where VM_MTE_ALLOWED is not set and KVM_CAP_ARM_MTE > is enabled. Otherwise a malicious guest can enable MTE at stage 1 > without the hypervisor being able to tell. This could cause external > aborts. > > Introduce a new variable noncacheable to represent whether the memory > should not be mapped as cacheable. The noncacheable as false implies > the memory is safe to be mapped cacheable. Use this to handle the > aforementioned potentially unsafe cases for cacheable mapping. > > Note when FWB is not enabled, the kernel expects to trivially do > cache management by flushing the memory by linearly converting a > kvm_pte to phys_addr to a KVA, see kvm_flush_dcache_to_poc(). This is > only possibile for struct page backed memory. Do not allow non-struct > page memory to be cachable without FWB. > > The device memory such as on the Grace Hopper systems is interchangeable > with DDR memory and retains its properties. Allow executable faults > on the memory determined as Normal cacheable. Sorry, but a change this subtle to the arch code is going to need a _much_ better explanation than the rambling text above. I also suspect that you're trying to do too many things in one patch. In particular, the changes to execute permission handling absolutely need to be discussed as a single patch in the series. Please can you split this up in to a set of changes with useful commit messages so that we can review them? Jason knows how to do this so you could ask him for help if you're stuck. Otherwise, there are plenty of examples of well-written commit messages on the mailing list and in the git history. Thanks, Will