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 44591D6552E for ; Tue, 26 Nov 2024 17:10:54 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7D1976B0082; Tue, 26 Nov 2024 12:10:53 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 75A626B0083; Tue, 26 Nov 2024 12:10:53 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5D4016B0085; Tue, 26 Nov 2024 12:10:53 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 3558C6B0082 for ; Tue, 26 Nov 2024 12:10:53 -0500 (EST) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id CCED741137 for ; Tue, 26 Nov 2024 17:10:52 +0000 (UTC) X-FDA: 82828885860.16.C54B11E Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf01.hostedemail.com (Postfix) with ESMTP id D48724000C for ; Tue, 26 Nov 2024 17:10:46 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=TO64gHFF; spf=pass (imf01.hostedemail.com: domain of ddutile@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=ddutile@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1732641046; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=pg1WH4/I0jZVgF7EzjYgTyBHdR/uKOZ3f0DDPVvbwns=; b=ItPmus7IERw/QdZAcjkJTv1eF9YRn7JWyvR2H0qLP2h9wCe/lUTbA00B0BKkj7yL6CxsBR O9HKueANqd1z1C54LheDLdh4J7dzPO0Vujo+68WQSbQxgTHxU9us0kFlmBcX6kEPeCYI+O JMRVJY/fC/ycdRE09HWsG3siXcSx4pg= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=TO64gHFF; spf=pass (imf01.hostedemail.com: domain of ddutile@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=ddutile@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1732641046; a=rsa-sha256; cv=none; b=i/OcfBR5Vq8L2VytOqhyWuzzTCXJUeOCu+PAKVM1HGVSMS/Q+PYrvaRRSdmm2OrWhgoxxf urCdl+sk9Nz2kZhrwC+xSoAvCY72oBUhRq3kf4DlDNMdrHQHpmwgVb4q8Bz6eKGDuJjGT4 n3p5BZoMpB/NV41jPPncSPSYxW8jNHc= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1732641049; h=from:from: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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=pg1WH4/I0jZVgF7EzjYgTyBHdR/uKOZ3f0DDPVvbwns=; b=TO64gHFFVF3WZ2Hy3LkLojzMAoMVIL7FzKP9qgL2OywrTH9ehwgNqMYUG9pgW8ysJ41nCs tCWMZ+l3W/7HC2N57mO4Iuh+FkOz+r9/FpUQCqqBOa2Gfn4+aIEijZ/BOVfywJcEf0OBOi Ne5nKc7DMj37nFBa5wuHZG9Cgq9hwas= Received: from mail-il1-f198.google.com (mail-il1-f198.google.com [209.85.166.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-169-5q_VbkG-MHO1KWJvDBtCsQ-1; Tue, 26 Nov 2024 12:10:48 -0500 X-MC-Unique: 5q_VbkG-MHO1KWJvDBtCsQ-1 X-Mimecast-MFC-AGG-ID: 5q_VbkG-MHO1KWJvDBtCsQ Received: by mail-il1-f198.google.com with SMTP id e9e14a558f8ab-3a76ee0008cso71606595ab.0 for ; Tue, 26 Nov 2024 09:10:48 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1732641048; x=1733245848; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=pg1WH4/I0jZVgF7EzjYgTyBHdR/uKOZ3f0DDPVvbwns=; b=vTWIHbyArbgsrWpRW5g3yhVhk3k5ZxfmXItXUnX5evNlolat0mlgxmsrKWOn03wIq/ OeFOse8A/TJZlMyj0/6VjGCshyR9LlQ6O55YF4OCT33YKqNMmhtfraMJdGLodX/Kqs8M soTSc79nCO/J4g882d3oZLH84Gc4GpYUp6zdtqum28GwSXZ9zHLmUXG6oPBw2nik70FF Sb2eJwWcWfcr9gAC73l96YEUp1fe2DFRFXlxQMNtVBLdxy6kNoP3fZNTa2+91LB1TreK 3YyV33lXia9+lPq3ml+Gz4uZl8IBKDPn6e7jAsdy5rUpiiK4O1WrS3yDiMnvSDq3n2R2 4RbQ== X-Forwarded-Encrypted: i=1; AJvYcCUqFfLjw2azsPEKv0hWsZjF6kCmYC/sW8vBpy/WjBk1f+KEOwOqWXGk+GS244pcVFWOTQ49VZWwcw==@kvack.org X-Gm-Message-State: AOJu0Yx+N4HHO+U6juq9g4IWdUCTrmYE4lhbQILXc7lA6YJEbaJq5lcT auJqlh6i4dSTt7WEbzJ7eMTTtPHDx5aEJ3BnEram5xtJHJ6QLNs8/3oym0Ibi0pFsxn3OKcgcuS b1JSUXyKyOqj2sIRgDsAeN2E0X9YOJJclQo6GZhFm6s1W9zhl X-Gm-Gg: ASbGncujxPHsvh8KrU3Gu1zh4ao2v1yUuSgTfU5/WNAjVsZiSAysU0FnJ9N9NsyfnD/ eE3BiEOHoknYkaOfg5YaN0Bcah7AeK4UCSmshLBVeWC8/wV1703l0caNiCU9YEBqj5ZPezxReLQ r1PYpF5yAaYmddYoFNE/+C5vHKFEWqHCkPe8ZdJLiaZWSw+tnJaCKuZASbb7fg/GIFCQO928iXp wFK1lzdYxLjUogCLJpTDI2fTKsKhJ5aFMOisebkxRAc2dDoE5w= X-Received: by 2002:a05:6e02:16ce:b0:3a7:8a39:269e with SMTP id e9e14a558f8ab-3a79aeea927mr188257385ab.18.1732641047494; Tue, 26 Nov 2024 09:10:47 -0800 (PST) X-Google-Smtp-Source: AGHT+IG6K6UNamiK6O/nxV7SHYbjCV/fiYY963jqY0jKdci5faeUGnSMsVF/gMvDkGoJTCkuUhR9iw== X-Received: by 2002:a05:6e02:16ce:b0:3a7:8a39:269e with SMTP id e9e14a558f8ab-3a79aeea927mr188256395ab.18.1732641046931; Tue, 26 Nov 2024 09:10:46 -0800 (PST) Received: from [192.168.40.164] ([70.105.235.240]) by smtp.gmail.com with ESMTPSA id 8926c6da1cb9f-4e1efbcaa5bsm1792326173.78.2024.11.26.09.10.44 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 26 Nov 2024 09:10:46 -0800 (PST) Message-ID: <07252361-8886-4284-bdba-55c3fe728831@redhat.com> Date: Tue, 26 Nov 2024 12:10:24 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 0/1] KVM: arm64: Map GPU memory with no struct pages To: ankita@nvidia.com, 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, will@kernel.org, ryan.roberts@arm.com, shahuang@redhat.com, lpieralisi@kernel.org Cc: 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 References: <20241118131958.4609-1-ankita@nvidia.com> From: Donald Dutile In-Reply-To: <20241118131958.4609-1-ankita@nvidia.com> X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: 0VCJGPlpyreSAgf9XsKlMmi5Oe0eT4uINcDvwLhlucY_1732641048 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: D48724000C X-Stat-Signature: iiq9z5mtmeehpoqq33nnmo7ub8jgaucz X-Rspam-User: X-HE-Tag: 1732641046-667659 X-HE-Meta: U2FsdGVkX1/bEmlS8YHcaneiaYl5iP1018l2ytsCyos2s2Uzve/pMRxxVPRKeukcYTem5huVyzDLY00L7ruvgokKbWv9l3Ya6Vdu3yhXRiwNjVuUVqRwnH0FIyoGY/Ai4lRfrCmgHglO9xz7S4SAqzDtah7QbV/efzjrA4+tMwFLQCCOK+FJPvvt2woOvc6LRq/fB7O/uqNbJucyw3wdR6gGVYhBLPNwqzyR/JeoBbLRojEDy4VI9U2pVf6ZAFAUfrABOQacnHhl0hjFqVotaKtXMdWyAvGxvfxQDfw7DmCmkvST0w3MczZ61ssYzrkbSTKhU1lUyEJp+hX2i+xq+R9i8fHtLcVsGDzt++tDSZxjXMGydOBdoDy5HDTnbi52aSXVarElBNYHdTRg6GwdpMrPo080LHGYeJr+EsEDYxeh0UAOY+nPOIoEmpTVlPupfimM3h7MeO6gy7581PDOucGxC0QbYlNAF1Up5cb6+RbfWNJVZDNaGK5DI/0yFK6tJsXqaWzcklDtGMXzfuk46qTuvoW9VYkg4hqO3ud94s1Uwg+gk3v7IYUlaCCgUlKfWGCgqLnn1jCJbAUVe66t/kDvQtxDQX2VH526LO9How3nTCOQ5E9+wal3/U4bKNPweB4VldqXkMfvxtuW+N9OOn0wjG/P4WPArDpMe7P4F4uTVrgti5MzSGBFAWRHatGgXsdLuaPY/SNfQoXQnjGhI3WIKtcaIzXiF055nFnz3+8QGW7BIByPCgT+dbb9fRWAYQSOp7iqHlc+N3jwkBn1TzAJ4T1AS9yH5mm4UcAKGoYQLMptNSILKnuYghOb2s8epPMUPTsxpUg/+wBFTj2DK5THzAerNZmE5JSUbVtTdnVIWsW6jKbzRs1ffUSRDMDMdp6YfGbU3xzCCNNl0Cg2xo+kMdOA3/xBDXwM/x1saci9qT9Q250c8ez2U6k1f68FJtBDQatcA0nojD1bUxx nUKkermM 1+P6u93EVW2do2UnfhkVg8eZeOBMm/M6AJBmjsAXnSp4caJJcsG//42RMY2wswhS5XU++yNm8yVmVr7JA/bi4ra36uvvhWN0GSxCv08zZWQjHPyAQYBCCqZgciXLpIcGigzEC0uF7jKScgC1Y6gwBEi1n4dDVJPU5EZgzbSbkmlebvJ7DqW/CMNYCicMsLytdFuyHD00D/0OetOZMGeIShydUDVC1iUgBQJAsNRMpKma+dHIG1uiraP1JSzY77xeHkGjOrBbNIbNOvuqK6EOuGu8d912qgE7oCTw0Q7dTfHiC/iPfvdVAQeZzwqJFvxJJjBbnWFfICQbnWYl8MYr+r0IL9vrrfM79YblSipGdI5tOw1on8f9cTP+5ObPv+/PxsBBL84EIovLlEx2AaM1QQOnEkxRMG8FR+J6b6ydhKJlZV9E= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: My email client says this patch: [PATCH v2 1/1] KVM: arm64: Allow cacheable stage 2 mapping using VMA flags is part of a thread for this titled patchPATCH. Is it? The description has similarities to above description, but some adds, some drops. So, could you clean these two up into (a) a series, or (b) single, separate PATCH's? Thanks. - Don On 11/18/24 8:19 AM, ankita@nvidia.com wrote: > From: Ankit Agrawal > > Grace based platforms such as Grace Hopper/Blackwell Superchips have > CPU accessible cache coherent GPU memory. The current KVM code > prevents such memory to be mapped Normal cacheable and the patch aims > to solve this use case. > > Today KVM forces the memory to either NORMAL or DEVICE_nGnRE > based on pfn_is_map_memory() and ignores the per-VMA flags that > indicates the memory attributes. This means there is no way for > a VM to get cachable IO memory (like from a CXL or pre-CXL device). > In both cases the memory will be forced to be DEVICE_nGnRE and the > VM's memory attributes will be ignored. > > The pfn_is_map_memory() is thus 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. > > Also take care of the following two cases that are unsafe to be mapped > as cacheable: > 1. The VMA pgprot may 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. > > The GPU memory such as on the Grace Hopper systems is interchangeable > with DDR memory and retains its properties. Executable faults should thus > be allowed on the memory determined as Normal cacheable. > > 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 changes are heavily influenced by the insightful discussions between > Catalin Marinas and Jason Gunthorpe [1] on v1. Many thanks for their > valuable suggestions. > > Applied over next-20241117 and tested on the Grace Hopper and > Grace Blackwell platforms by booting up VM and running several CUDA > workloads. This has not been tested on MTE enabled hardware. If > someone can give it a try, it will be very helpful. > > v1 -> v2 > 1. Removed kvm_is_device_pfn() as a determiner for device type memory > determination. Instead using pfn_valid() > 2. Added handling for MTE. > 3. Minor cleanup. > > Link: https://lore.kernel.org/lkml/20230907181459.18145-2-ankita@nvidia.com [1] > > Ankit Agrawal (1): > KVM: arm64: Allow cacheable stage 2 mapping using VMA flags > > arch/arm64/include/asm/kvm_pgtable.h | 8 +++ > arch/arm64/kvm/hyp/pgtable.c | 2 +- > arch/arm64/kvm/mmu.c | 101 +++++++++++++++++++++------ > 3 files changed, 87 insertions(+), 24 deletions(-) >