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 4A29FC61CE8 for ; Mon, 9 Jun 2025 14:21:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D7F0C6B009E; Mon, 9 Jun 2025 10:21:20 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D57096B00A1; Mon, 9 Jun 2025 10:21:20 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C6D2C6B00A2; Mon, 9 Jun 2025 10:21:20 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id A741D6B009E for ; Mon, 9 Jun 2025 10:21:20 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 56C27140530 for ; Mon, 9 Jun 2025 14:21:20 +0000 (UTC) X-FDA: 83536074720.02.BD48333 Received: from mail-pl1-f202.google.com (mail-pl1-f202.google.com [209.85.214.202]) by imf04.hostedemail.com (Postfix) with ESMTP id 976E040002 for ; Mon, 9 Jun 2025 14:21:18 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=iif57i21; spf=pass (imf04.hostedemail.com: domain of 33e1GaAYKCB4M84HD6AIIAF8.6IGFCHOR-GGEP46E.ILA@flex--seanjc.bounces.google.com designates 209.85.214.202 as permitted sender) smtp.mailfrom=33e1GaAYKCB4M84HD6AIIAF8.6IGFCHOR-GGEP46E.ILA@flex--seanjc.bounces.google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1749478878; 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=LSIEw/2MydfV3kI4WHDS//5IkvGuSP6WLCIhrE/jR14=; b=Cy8W80IKe4T/ZY8WotLTL+c9YtJt2NYfpZUO/khta39CTTa52iQOFtDnFf9GbB3bxiNnOb yBDuU7XseYjjM2IC7Gf4XikJJuRG+OXuoXh9STmQenudYmvvSWwmFpqAO1WdRem/mJ919x qmNoyuP1BD7hwQe58C79nQDGEaOusoE= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1749478878; a=rsa-sha256; cv=none; b=A0CJ+2bNCPI7UOxM6RUO/R1ZxIPHFpf2wmi9yeeDJgl8W/bswee31l/LyW9iah8QIjMAiB 3cD7ZDWjsxyH4Vw6Ogc8GaJhwcsN1tMNDfukjzo+32jaP7m6TRgI2tU1Xac0mlQKCBfO9U TKzPR995q19Afq6ojV+1dymjttE4efI= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=iif57i21; spf=pass (imf04.hostedemail.com: domain of 33e1GaAYKCB4M84HD6AIIAF8.6IGFCHOR-GGEP46E.ILA@flex--seanjc.bounces.google.com designates 209.85.214.202 as permitted sender) smtp.mailfrom=33e1GaAYKCB4M84HD6AIIAF8.6IGFCHOR-GGEP46E.ILA@flex--seanjc.bounces.google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-pl1-f202.google.com with SMTP id d9443c01a7336-231d13ac4d4so67424425ad.3 for ; Mon, 09 Jun 2025 07:21:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1749478877; x=1750083677; darn=kvack.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=LSIEw/2MydfV3kI4WHDS//5IkvGuSP6WLCIhrE/jR14=; b=iif57i21rw6Aq2p/P0KLvFmcFtGEqjzn8Vx6M9kooT9AMgE4yLHnS2IRxrkAr0V+UH hW0xMS4BFK61Wqq5GQXF6tEa2Kb3T8mNNUxWACfPi0fji4NW4aw1YxckPxGdJ6gEyopC fHIlPHEm8kieoRjq4ozkl7+m3HmZ/Ly467D8u7z2pKNgG7YUkRK/DiFRtnM74glwUoVr Hub9pcQ5jLQQGyHYB5fJYChx6W43C5vpaNTG2VROXtfQBMZDbGPSdKEhV8ohiK3c9jeg SyPn44PrsTpohi68zWW2jGwvg1vE+uNAQu9bAfQ3CrlifbEEmoe+csoD4BiFDPcgn7Sg rZ2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1749478877; x=1750083677; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=LSIEw/2MydfV3kI4WHDS//5IkvGuSP6WLCIhrE/jR14=; b=P2kOWvHQYBMeBJZbmh3KagME7ZihqhOycGQrrLOljI2o1cGwVKsG5zIIDjGkdYQyun DiFiDIKOqWmXUT/vW2ppFKKaD+fnDXpvDqg7jJSnmFLaClQ+Giq4lhKCCR9aL2sbIucc S4ZfbInaIAzYtE7HS+SJBX2/ATD655fB1nw9q0Hb1iJMuGXWhjUSyilp3ykOrsxlrmV6 vlqwobRzjKnHS1cCqavMiPPduA9+Zy9r389i8NTg0Ovaa6LItlZZrnEYI81bhJ7LRWHy lc24Dm4nD7sVMp7clM9tYzbJGX/bESBKnZV98cD9j4UNRkgHPrw3k8fo//8+u6Xi5MsZ t5Fg== X-Forwarded-Encrypted: i=1; AJvYcCWh4NglJehFUTb35yP19bqRhxPvOLLMaUS2IEmVLno8BMDxeAB9YODxKImTWG4wQiO/r4kpdFD5uQ==@kvack.org X-Gm-Message-State: AOJu0YxVuCetBpkfTFE3Pr4pVVOsTHlcJYXNRLnaClKV3SJoYayoX+dB JnRCPfsyYt/0JdjXt5UPNU7JcJc7M+GncZaLsQdH/gaDItQMLY8TV4KI9rAWDlmnsvzjI3HtDX1 Aa5MSIQ== X-Google-Smtp-Source: AGHT+IERysFaxhAHifqxHTi2VcbI8oY5rYOLco6ZrI9WGaP0rXEe5OjT6M/29a/9l0QmkI+VOJHg1ucx2CE= X-Received: from plbju5.prod.google.com ([2002:a17:903:4285:b0:234:45eb:5e18]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:902:f544:b0:235:f3e6:467f with SMTP id d9443c01a7336-23601cf6bd8mr192715225ad.2.1749478877172; Mon, 09 Jun 2025 07:21:17 -0700 (PDT) Date: Mon, 9 Jun 2025 07:21:16 -0700 In-Reply-To: <20250609122402.GM19710@nvidia.com> Mime-Version: 1.0 References: <20250524013943.2832-1-ankita@nvidia.com> <20250524013943.2832-2-ankita@nvidia.com> <20250609122402.GM19710@nvidia.com> Message-ID: Subject: Re: [PATCH v6 1/5] KVM: arm64: Block cacheable PFNMAP mapping From: Sean Christopherson To: Jason Gunthorpe Cc: ankita@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, david@redhat.com, aniketa@nvidia.com, cjia@nvidia.com, kwankhede@nvidia.com, kjaju@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, ddutile@redhat.com, tabba@google.com, qperret@google.com, kvmarm@lists.linux.dev, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, maobibo@loongson.cn Content-Type: text/plain; charset="us-ascii" X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 976E040002 X-Stat-Signature: 89gon7c8x3jcngk78oz6k3nxkzt3ry31 X-Rspam-User: X-HE-Tag: 1749478878-928149 X-HE-Meta: U2FsdGVkX1+7EWLn3lvMauIDO0bCfSW0ScQAJv+QupLIQWNA5G1lVxrAM1hqAkq4rrooWTTy7jMBHVI9Eovq0Zb+QJbtqFmCey26N/3UB8wtCMxRse7cEKrRuH5vRB2icdDKhVeo1dAjoxeBGRNWAjrFZIO97YZnHQApe531tR0IRxQmmDgLzfUyVtuZY+yM4zq28PuHM/0UdssG2j3lVkQcoxdDYO1r2RFpaF1Ww+5pfJzxlRiRbGvAfxgETKOsUFxSaNJxppDAnzrnpXbC1UtKubbfKw45rGYM5JI9ZCtd/hmL5s//oNh/g0yKSomJcZGrtOU1G9pKVOiN1aDZBZN3G5D3wHOM9fm8Ut2h1GzEMR5LRJojvpfwAIPEihlZ+AyKJLVUDOjyqB1DkLNXkWcS59/tvXwfI6TqXljb2NP+AxZrpUuibP2fPHkMvN2wVQB3llsfng21dvGE6gspyY8UuHQVMQJ8gC+HjZCj8TQ8ieDt4oRcqMyQR0NkvcXginsSPwZ2sBlBA9tXgaKdvjwVjSDXLG7HPq+QByxee8+IA/XfxNI9h2oM2yD7LgW+8xEvclKjKp8MXMDSO8iGB5OSANSJjmvciNcaM3PPs8EAne9Uk6QpOJgqeW2RhVj75asJaLfkwXkJBT2dxOBZUp0XWiPXfSFa/xrg3gWelySbhnL27xsgRspyFKkwfiwH0NYoQfphTqZAIzLUANIr9b9dUhBksOtx/dMF2XMlY3sJVjcluBKBfXrm162VzvsREDQ5b306BKO6rA7dnd44idiWNxYJxZFT+2InNTMErYO2VPhmStcrdlXFQhzDS3sF3DQyo+8KnAbhXaA0ru/teFb+1nuGC+yi1QB2WZXufDs5ttGTCPEP/1cNACKTETg2/4cR5Ht86KpFk72KrolHFC/yzfCXOh/39tdAOduORQ9qVrQHVPClc0QLQ96H2XBsEP7D4hgk5S62m5RRLhL RMFac5c7 +8cng38+ZyW4Fd2wspAhFjX1VA0S+fucFjF0WOm/6tTYGL7chy7rCdjqPotSeNwsh/Q++go0x17DyBYyrqysJqLPWY0LkXXips6t27emkCp8BH1dEDR+d5Ja+cEy0W/v1jH9fb1Ej0BBIkMZDPuZklOSajLAteriUOcv5N2TYmNZMFvHWK9zCn+p0aOOfiWwVwz+Q8oW6c5bkKlvTEZms1c78iC/54KBjNm/cfzu0iCwiTT6Fnz9gFl9uHVo/AkTizHgrFbEiQVM48zXheiEyGTz6X/0OzcTJopGEPNzIjn7wgzF63Ig3PQdPAYdyxQ3e6KLesB534zYAkNaiK0/VywnkJZGxfiwV/n9DfHFit/SLx2YswOZzVLo8adR/ZJZ0xZNYwg4acVKs6vDrimJI2GEjDxdyB60DGg3ncQ9p6DuUlpYbTwQiyTlGBWgMAXtzZv0K1pmGW7sytt+BxWTyqJ5eW8pVwsJqUha/zSCcQE9CQ/N1M1djo0i+MboG6fsSttMd/HVmCnZpuVqBZa5lQVLKZiigpIFRpIsZ47q7CKKnRUT545MPfJA6k+rRMANdDR98C0k6k4Ij3nGfFEqnDNxOeQ== 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: On Mon, Jun 09, 2025, Jason Gunthorpe wrote: > On Fri, Jun 06, 2025 at 11:11:56AM -0700, Sean Christopherson wrote: > > > @@ -1612,6 +1624,10 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa, > > > > > > vfio_allow_any_uc = vma->vm_flags & VM_ALLOW_ANY_UNCACHED; > > > > > > + if ((vma->vm_flags & VM_PFNMAP) && > > > + !mapping_type_noncacheable(vma->vm_page_prot)) > > > > I don't think this is correct, and there's a very real chance this will break > > existing setups. PFNMAP memory isn't strictly device memory, and IIUC, KVM > > force DEVICE/NORMAL_NC based on kvm_is_device_pfn(), not based on VM_PFNMAP. > > kvm_is_device_pfn() effecitvely means KVM can't use CMOs on that > PFN. It doesn't really mean anything more.. Ah, kvm_is_device_pfn() isn't actually detecting device memory, it's simply detecting memory that isn't in the direct map. > PFNMAP says the same thing, or at least from a mm perspective we don't > want drivers taking PFNMAP memory and then trying to guess if there > are struct pages/KVAs for it. PFNMAP memory is supposed to be fully > opaque. > > Though that confusion seems to be a separate issue from this patch. > > > if (kvm_is_device_pfn(pfn)) { > > /* > > * If the page was identified as device early by looking at > > * the VMA flags, vma_pagesize is already representing the > > * largest quantity we can map. If instead it was mapped > > * via __kvm_faultin_pfn(), vma_pagesize is set to PAGE_SIZE > > * and must not be upgraded. > > * > > * In both cases, we don't let transparent_hugepage_adjust() > > * change things at the last minute. > > */ > > device = true; > > "device" here is sort of a mis-nomer, it is really just trying to > setup the S2 so that CMOs are not going go to be done. > > Calling it 'disable_cmo' would sure make this code clearer.. > > > @@ -1639,6 +1653,9 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa, > > return -EFAULT; > > > > if (kvm_is_device_pfn(pfn)) { > > + if (is_vma_cacheable) > > + return -EINVAL; > > + > > eg > > if (!kvm_can_use_cmo_pfn(pfn)) { > if (is_vma_cacheable) > return -EINVAL; > > > * If the page was identified as device early by looking at > > * the VMA flags, vma_pagesize is already representing the > > @@ -1722,6 +1739,11 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa, > > prot |= KVM_PGTABLE_PROT_X; > > > > if (device) { > > + if (is_vma_cacheable) { > > + ret = -EINVAL; > > + goto out; > > + } > > if (disable_cmo) { > if (is_vma_cacheable) > return -EINVAL; > > Makes alot more sense, right? If KVM can't do CMOs then it should not > attempt to use memory mapped into the VMA as cachable. Yes, for sure. > > if (vfio_allow_any_uc) > > prot |= KVM_PGTABLE_PROT_NORMAL_NC; > > else > > > > Regardless, this seems good for this patch at least. > > Jason