From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pg1-f199.google.com (mail-pg1-f199.google.com [209.85.215.199]) (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 8E656490BEA for ; Fri, 14 Aug 2026 18:13:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.215.199 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786731199; cv=none; b=X+bboyYoxlq5k0lkMZWS5ZXrdJk9+mctJUuH+YdzTYRsB1qI7F5BunCOgpQ+/HYtFEZxOYbdkogxNhava/ExQMRQqA6yiBXYdUyw3mu9JbHpNVxhdH/d0Ub2Gp0zDIIyI2EwqLCWUDFgbRbvZZ8MmCBaGelBszTtkCxfEeCLLCk= 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=ZSbW2En2; arc=none smtp.client-ip=209.85.215.199 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="ZSbW2En2" Received: by mail-pg1-f199.google.com with SMTP id 41be03b00d2f7-cbb6433e9d4so1635749a12.3 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=vger.kernel.org; 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=ZSbW2En2KcTkVZRa6xD5qWELlYHpboqrxgh02e2JgPBb1SOig+KanT6qe58sUaPiWo wh/f4dkLRF/r6XiCaNquo5CDDfVcsAvB/b2gG6P45O75XRiY5x1ZMWVorH/imzJW7xFE un2Ts1kjLA8usg4wQyiYMg8Zf+sT9x80SpotqP0pvTTAeikHgNFO/z+cWAzDWbbbGYnr svJb8Uk4IebGj+EuJUdpE7z0mmwD8RbDusiGpqcEssCkUCkgKrHBt7YgotonIlNoE/IC eWb7ygH14/ELtAKzUUhNGKFjEZxqPnlUrv8MhQooYL2VJXJBeMW2eTFBPQtCUAtNxzBe g7cA== 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=S3+iXpybiqgF05+eKGUJ/AXcNsqy/tlJhHoU1kizLH3tqvfsiMiC/9ShamxF7FVRsM dczBFhD6j7h6sr5PCjNGhbB+nNRqnGbgVyD5AqW1iiK/tnuaCTkmHWgo6Bed/Dv1kReI 17dpxCFJLcroJdOaiAB9TJeMlIy7SmQ9U1HBYLRKN17owOfS1R9MLVw83T9sRzgtwMH1 QVOCsnSsmlpP/7rwyrHU9/AAW9Vfc9P7beBTGmTUlnuPgIMVCzAkYLlO9x0HTw9gM3FH TpRYuZ9po2tbsOAAv5YIDzOqM+ilYbE6L/UTrdxVMG5O5GxrUjrsM9Sr2wHWGhIRbZ7/ UJVg== X-Forwarded-Encrypted: i=1; AHgh+RpVpMJ3pCd2QO8a4yCNqR/DlgQplVdtf1z7dIJDDs34gxCervUIJtiXCbHUDX07pevJgZ5G8efryNJuZGU=@vger.kernel.org X-Gm-Message-State: AOJu0YzP5RKjcBV0ZkVewCLGj0dUhDMh+H6gaJGoENVsW0lvkSpzUOCS 1odqjBCnfdtSnAECSVRCt8hoY1HJkvPGTdaHNWXMzmTXi84Jfmw9ERKwT9CPLqX9oT43OIszJHd FisnMmQ== 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-kernel@vger.kernel.org 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.