From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pg1-f197.google.com (mail-pg1-f197.google.com [209.85.215.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8FE1C490BED for ; Fri, 14 Aug 2026 18:13:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.215.197 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786731199; cv=none; b=Gqo4TLi/sk/HX8w1pAfLQ1yLoF/jV+h3OFGa2ZlxkF9s1KHtQMqKAe2+ArvigopikZQd+cA7gk4CozfUzuABs+17vT2DWglPNHyG+lNRR39zQP5xOGxoNYba3tf2PrEXRw0dThjIbekInQTxHPmnQ3vwtOvXPRtsXF3pBOgtCUM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786731199; c=relaxed/simple; bh=OGjC4lU1LA7/XzaG6yfv4mKkKwAbvoqsVMSYuVRL2fk=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=uEj1ZJa5idVEitoarzYsUzCPVeexlc1d/7xP/yeDuyAYtrXjgyVGzumvxJhJS0s1Y84sOkByumE8ZvmuTlzfcwAg/gpUyNt7ek245SF+PN1kNwpYMEg8LNyhI5dP0v3+amvNFwraytCHJjA1b1GosbytdtRsgdfJvLhxIedYpr4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=u4tL14b0; arc=none smtp.client-ip=209.85.215.197 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="u4tL14b0" Received: by mail-pg1-f197.google.com with SMTP id 41be03b00d2f7-cb5ea36f969so1425921a12.2 for ; Fri, 14 Aug 2026 11:13:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1786731197; x=1787335997; darn=lists.linux.dev; h=content-type:cc:to:from:subject:message-id:references:mime-version :in-reply-to:date:from:to:cc:subject:date:message-id:reply-to :content-type; bh=IXgZWbJY+AFNvGsunVK4VPpL85oG6gcjHAIado0UDKw=; b=u4tL14b0VjywgP4MCkZt5sanciUftl23pq8FuwfTCEPgawuMRKsUQcZGbCwGB6eDEo M/zbKWY6D0l082KFCcjYmAdVJ9OwfKnKOUvqhgTNrWE9yChX5dbTQOs0A/ZEh2rDZMW2 9edIvTpD8Wq1n5CvFSjxXj7oGRyQJgehQRpk1U0HpViuyedZP5QV/jUt6xV9wPLc5GU3 XiGhxDaYX34ja/K+ScUtRPMDbHg0Qx9FG3Xy1jdJm1soGcg1sXzOtUIDQtmf/XWQ5HTb ke2JbrRkkKHrgzc1V80dDnW/TTm2wxA6EX+xjDwJhYvrGB4p/bsSb0D0QBHQ+1r7mmsP FH4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786731197; x=1787335997; h=content-type: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:content-type; bh=IXgZWbJY+AFNvGsunVK4VPpL85oG6gcjHAIado0UDKw=; b=Xzy3yAdGe7IuoiQzD11+y3D/CYlFvjB4BQ0v9qTDPv7Vr1+V2+NWlapPOhCYgZ0+Vo xBTdJ6jW6fBm4eESdDzKnBn6X318m/fm9Gjeu4peLgmW9Ljbjj86tI5nHWIEHHx+EgCR wFURBTEZAcKGTgWX72V4v3WJl8KTZTVUSsNDyuD0r+uJyftAtHhx6ygxGMmZeEpnwm9v Eug5ELNnNChheXFWSINxh90/mgCfShiFLLGMbVuozGG/kJjIEaHJgw0/xn3/X/UJLPXz XOqZR835z8girJIlRmX9YNo75cMbLdINqyeRVNdav/LgUtGtLd0CcJHQiPAzmr+Dmp33 rOCQ== X-Forwarded-Encrypted: i=1; AHgh+RpEfq3q/johCbAnno2vXEQhStxERKyHX/hjqzj5Gz54CqUAHajRhuk8t4EFPQJEksetmAa1IIgE9fOw@lists.linux.dev X-Gm-Message-State: AOJu0YzJxLsizG/u/RuxNWLC+vXhjNMJVJvzA5yNs35/03wv60Qaoplc Xqeh6xpN0rOPe6jTnI0vUxnfv1IY3Sp+6San6JFMkdTbtzpHRnC+XeHJ8EGTvlNHQTu7+gtlF6a idqkutg== X-Received: from pgkg8.prod.google.com ([2002:a63:fa48:0:b0:c9a:d174:5315]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a21:7316:b0:3c4:de3:816c with SMTP id adf61e73a8af0-3cc71ed56f7mr9388112637.37.1786731196579; Fri, 14 Aug 2026 11:13:16 -0700 (PDT) Date: Fri, 14 Aug 2026 11:13:15 -0700 In-Reply-To: Precedence: bulk X-Mailing-List: linux-coco@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260807-gmem-inplace-conversion-v10-0-2fc18ee6d3ba@google.com> <20260807-gmem-inplace-conversion-v10-20-2fc18ee6d3ba@google.com> Message-ID: Subject: Re: [PATCH v10 20/41] KVM: Let userspace disable per-VM mem attributes, enable per-gmem attributes From: Sean Christopherson To: Binbin Wu Cc: ackerleytng@google.com, aik@amd.com, andrew.jones@linux.dev, brauner@kernel.org, chao.p.peng@linux.intel.com, david@kernel.org, jmattson@google.com, jthoughton@google.com, michael.roth@amd.com, oupton@kernel.org, pankaj.gupta@amd.com, qperret@google.com, rick.p.edgecombe@intel.com, rientjes@google.com, shivankg@amd.com, steven.price@arm.com, tabba@google.com, willy@infradead.org, wyihan@google.com, yan.y.zhao@intel.com, forkloop@google.com, pratyush@kernel.org, suzuki.poulose@arm.com, aneesh.kumar@kernel.org, liam@infradead.org, Paolo Bonzini , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Steven Rostedt , Masami Hiramatsu , Mathieu Desnoyers , Jonathan Corbet , Shuah Khan , Shuah Khan , Vishal Annapurve , Andrew Morton , Chris Li , Kairui Song , Kemeng Shi , Nhat Pham , Barry Song , Axel Rasmussen , Yuanchu Xie , Wei Xu , Youngjun Park , Qi Zheng , Shakeel Butt , Kiryl Shutsemau , Baoquan He , Jason Gunthorpe , John Hubbard , Peter Xu , tarunsahu@google.com, Vlastimil Babka , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org, linux-doc@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-mm@kvack.org, linux-coco@lists.linux.dev, Xiaoyao Li Content-Type: text/plain; charset="us-ascii" On Fri, Aug 14, 2026, Binbin Wu wrote: > On 8/8/2026 5:52 AM, Ackerley Tng via B4 Relay wrote: > > From: Ackerley Tng > > > > Make gmem_in_place_conversion a module parameter so that userspace can > > configure enable or disable the use of VM-level memory attributes. The > > module parameter is only available if CONFIG_KVM_VM_MEMORY_ATTRIBUTES is > > enabled. > > > > To avoid inconsistencies in the way memory attributes are tracked in KVM > > and guest_memfd, the vm_memory_attributes module_param is made > > The description is stale, since there is no module_param called > vm_memory_attributes? > > > read-only (0444). > > > > Since selecting CONFIG_KVM_VM_MEMORY_ATTRIBUTES disables in-place > > conversion, > > "selecting CONFIG_KVM_VM_MEMORY_ATTRIBUTES" doesn't necessarily disable > in-place conversion, it also depends on the setting of > gmem_in_place_conversion. > To be accurate, maybe add "by default"? +1. Ackerley, please write changelogs in imperative mood, i.e. state things like this as command, not as a passive description of what the code now does. And I would omit the blurb on changing the kvm_arch_has_private_mem() definition, for me that falls into the category of giving a play-by-play explanation of the code change. I.e. Let the diff speak for itself. E.g. Allow the user to disable KVM_VM_MEMORY_ATTRIBUTES even when KVM supports PRIVATE and SHARED attributes, and expose gmem_in_place_conversion as a module parameter when per-VM attributes are supported. I.e. let userspace enable in-place PRIVATE<=>SHARED conversion of guest_memfd pages. Provide both a Kconfig option and a (conditional) module param so that deployments that use a custom kernel can fully disable per-VM tracking, while not forcing distros to ship two separate kernels in order to provide backwards compatibility for downstream users. Don't allow running VMs with mixed tracking for a given instance of KVM, i.e. disallow toggling the module param after KVM is loaded, as the extra complexity needed to handle per-VM behavior far outweighs any potential benefit. E.g. neither TDX nor SNP supports live migration, so in effect the requirement is that existing deployments that want to support both the old and the new models would need to tell their VMM which flavor of tracking to use.