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 75802C71136 for ; Fri, 13 Jun 2025 19:38:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 146006B007B; Fri, 13 Jun 2025 15:38:38 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0F74C6B0089; Fri, 13 Jun 2025 15:38:38 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F278B6B008A; Fri, 13 Jun 2025 15:38:37 -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 D00676B007B for ; Fri, 13 Jun 2025 15:38:37 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 6EC405E984 for ; Fri, 13 Jun 2025 19:38:37 +0000 (UTC) X-FDA: 83551389474.23.62E53B3 Received: from out-187.mta1.migadu.com (out-187.mta1.migadu.com [95.215.58.187]) by imf08.hostedemail.com (Postfix) with ESMTP id 5A0DE160011 for ; Fri, 13 Jun 2025 19:38:35 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=nHVMfSp1; spf=pass (imf08.hostedemail.com: domain of oliver.upton@linux.dev designates 95.215.58.187 as permitted sender) smtp.mailfrom=oliver.upton@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1749843515; 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=05h3cJJBxazbpz5FiVZjgC7ryx5+viWkk/L4vbZmO2k=; b=jsHDfYa73KMIn5Vy1mM6to/9H9cp04ECdsC/evV7HKuqoa6JNXOujjTtwXUQcpUFQ6n6Mm UXxxF9PpfL2saYcEnTJEBVaOhIGKB5DiMqVrRn10r80CUEF0FBLvxZ6mriIXg4K+p3hwlK 8vl6UkwI5bp5iXLghAzMWMZTK5mNA2c= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1749843515; a=rsa-sha256; cv=none; b=Lm9IvJNeY2ZhsfE8oGYxeW5/j+36mnhcfk6i8Itmq2rFOvqvKdmMPKGkzJVU38mEIf4hqa gBz52sNZOlXvUmlDeFXW1NQGvLbOR9/5jNmW2P0tBgcLAmybZBHxwM/m/BweHkkaHqUdnB IEBYsFy8mSryoo5yAYPvj0dC12HMZ/Q= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=nHVMfSp1; spf=pass (imf08.hostedemail.com: domain of oliver.upton@linux.dev designates 95.215.58.187 as permitted sender) smtp.mailfrom=oliver.upton@linux.dev; dmarc=pass (policy=none) header.from=linux.dev Date: Fri, 13 Jun 2025 12:38:14 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1749843512; 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: in-reply-to:in-reply-to:references:references; bh=05h3cJJBxazbpz5FiVZjgC7ryx5+viWkk/L4vbZmO2k=; b=nHVMfSp17TO+6pXWRN4z4CUhv9KXUKZYW16bR+BF10UJ7m/uUOfxNwfBQwC4twFlBHRKSw Pf4lttmhhbapozJhj8WeTWmvaEhliYPwyic1QqNvnmgCUFm2IwxzdvvDpp7lJZ6EY7EXPe YehBIglTD6fsw9/Y9qBBC2aqrl5gBus= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Oliver Upton To: Sean Christopherson Cc: Ankit Agrawal , Jason Gunthorpe , "maz@kernel.org" , "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" , Aniket Agashe , Neo Jia , Kirti Wankhede , Krishnakant Jaju , "Tarun Gupta (SW-GPU)" , Vikram Sethi , Andy Currid , Alistair Popple , John Hubbard , Dan Williams , Zhi Wang , Matt Ochs , Uday Dhoke , Dheeraj Nigam , "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" Subject: Re: [PATCH v6 3/5] kvm: arm64: New memslot flag to indicate cacheable mapping Message-ID: References: <20250524013943.2832-1-ankita@nvidia.com> <20250524013943.2832-4-ankita@nvidia.com> <20250527002652.GM61950@nvidia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Migadu-Flow: FLOW_OUT X-Rspam-User: X-Rspamd-Queue-Id: 5A0DE160011 X-Stat-Signature: aikrdpnb6chwwyu8a9u6n3q4wd9tyhos X-Rspamd-Server: rspam04 X-HE-Tag: 1749843515-322796 X-HE-Meta: U2FsdGVkX1/o2p1rnnLv8+Q/5AB2VvLiGKRYq48ZfR7/inonSMvp4nuJj67za+MAVKW45q/vqql0UYaHzK7RWS7SXb4SbTsR5kn10b07COwdnzbIihmrRAgsvbpMZmW4FKL8CMfZPhL4++HKHBGrsvZMmDALdgwUZzzqBUZX0zFMqwLB2xzyqxtX5Zb5EMFcUjE+YqtIN6sxDKJryZwMaxtAcrgGDAsvfj8Dw/g/kAF0kjt8/cqAwCrRbTcPZzpeKA4B7rN8LiSUluOdDynrnJ1Y6TqgxQmGMiitpQP8coyJMOCH6fwdoFQ1YnkgU6F47oQyCNkij8NVs9Cl4XK96eU+IdRHYthYRgNA1m5S10pk8Z+atlJZpkvwM70m1F/T4Reu/BDD6M+PRVrKKBEPCSWkkysMqfzLwF7tZhwtwDoKgTkKfR578a7o7lI3C8TlbUTnG6cvMt5hfnQVQ3FpV7qX6sm+5IUd2lrKSxBcDHbmPnxgO0jbJbFP6L8uRSzdP6F6mTDGNWJvjtDqU/zlA88iRvbRq15EbsnrLjstugqqarkDsmcGqXc1cir2QGSy7wdJ6i2+We5dEd6bXG3LyhMIQ/CfTh66dA0vz8Yx+onjnEY0BkKpUxvNscoCFxITX5F0TJyTM3kkzCvzqX4XyTOG8y4erBI/wMI2EQHJxO8w9ZbQXZkwFnhdHsLY91VsOUWEA0fDYy6AHG82+KM2yKPDQrUdOAAnPQFa6gyUDRwVQcRVtz6Ylv8vFbj5HEx/cZ0O07AgtsfGiv93vkLjulbgyjRI6aJKWkl2arSZYs4+1YzY+SrawXCQwKUKzz90c3O1w6Tf6LBbJ1gAOo+sSVwS+QlxBog4OzOpJj0pvNXbAl1bPgEa25rwtIbTkW/yssUl/ABh0TN6d3hg1lKHXhJWPKkcxPI1UsSfspCxFyDO9EiN4bQRuI/H77KNFBmn7aCEq5fLUTVX9QQ3wCN c19PrnHL glaHlQbqUZ6eZpE97fVmj1yAjRx93wOXlfco3v2RWHjiRBeVw0ZTQPDY4RFT+Tj57Cw5u4NiBHd7G6vZ1SDvLhMIb6kV1iQNKNuY9KMO+6xEBkyesxc6MwCs9QsiLt+J0NmRoM/P0/XVlfBqQsKb/lezFuBkL1zOetYb8fzhB/VFK3jQOEOCRRH+4ZMaMiG6SgG/MKZ5oIpj2xbTDj9hB38XG7v/s1UgmItAFl56Lht7pYrrsoyzbainHVPN9RNepQJ1BlxzQcVtT8Tj0Fuqu6xXhX3bDGJpl5ziV 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: Hey, Sorry for going AWOL on this for so long, buried under work for a while. On Fri, Jun 06, 2025 at 10:57:34AM -0700, Sean Christopherson wrote: > I would much prefer we have a way userspace query the effective memtype for a > range of memory, either for a VMA or for a KVM mapping, and let _userspace_ do > whatever sanity checks it wants. That seems like it would be more generally > useful, and would be feasible to support on multiple architectures. Though I'd > probably prefer to avoid even that, e.g. in favor of providing enough information > in other ways so that userspace can (somewhat easily) deduce how KVM will behave > for a giving mapping. Agreed, and really userspace needs to know what it has in its own stage-1 for that to make sense. The idea with a memslot flag is that you'd get a 'handshake' with KVM, although that only works for a single memory type. What's really needed is a fine-grained enumeration as the architecture allows an implementation to break uniprocessor semantics + coherency for _any_ deviation in memory attributes (e.g. Device-nGnRE v. Device-nGnRnE). Although in practice it's usually a Normal-* v. Device-* mismatch that we actually expose to the VMM. So, in the absence of a complete solution, I guess we can forgo the memslot flag. OTOH, the KVM cap is still useful since even now we do the wrong thing with cacheable PFNMAP so KVM_SET_USER_MEMORY_REGION accepting a VMA doesn't mean much. Burden is on the VMM to decide what that means in the context of $THING it wants to install into a memslot. > > > There is no easy way for VFIO to know to set it, and the kernel will > > > not allow switching a cachable VMA to non-cachable anyhow. > > > > > So all it does is make it harder to create a memslot. > > > > Oliver had mentioned earlier that he would still prefer a memslot flag as > > VMM should convey its intent through that flag: > > > > https://lore.kernel.org/all/aAdKCGCuwlUeUXKY@linux.dev/ > > Oliver, could you please confirm if you are convinced with not having this > > flag? Can we rely on MT_NORMAL in vma mapping to convey this? Yes, following the VMAs memory attributes is the right thing to do. To be clear, this is something I'd really like to have settled for 6.17. > Is MT_NORMAL visable and/or controllable by userspace? Generally speaking, no. Thanks, Oliver