From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f201.google.com (mail-pf1-f201.google.com [209.85.210.201]) (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 C3B8B3B9DB6 for ; Wed, 24 Jun 2026 15:12:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782313954; cv=none; b=E65wKFbyTUG7X0TgxsSniMcLq5WyGOB3u3GTINcfdruVPk4XPHoFMy0gQa9Hpx8iTbyeS/KSERYLiRsfgRIh0Me8ii2xipW1bTF1uu4ZRBKl9q2LGWrjSjqSgTMKjcalC6XyWr8mntE5FYPWc9dzcs1dDJ8Lcn1y65seeecjKgo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782313954; c=relaxed/simple; bh=YQ3/8MH+pHOzHZgS6t1eRUhjOfffeihprBIIfnMF1y0=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=q0pFDQZNTpU8kj9kwXO6yL5sd6ixLY0NodNORO1ITFHOect41dBg9A5WU+Y2L9bOaGsfLNYOZjM3V3UrmiyA9ADuxqLhLngF6/wEH/LKaG06epW8PYioLOTiORzVfDavXWDGnJiwk56l3D9cJAgdTxdZGdxYbjtJ0LoQep5/WiM= 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=YnGzROfu; arc=none smtp.client-ip=209.85.210.201 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="YnGzROfu" Received: by mail-pf1-f201.google.com with SMTP id d2e1a72fcca58-8454912a507so2040170b3a.2 for ; Wed, 24 Jun 2026 08:12:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1782313952; x=1782918752; darn=vger.kernel.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=r4Rgqs0dmpAmBtoUIzRDi3XnAOaTZ7bU1jnGrXxRY7M=; b=YnGzROfu7qCNjuudkIxxEtTx9kMMyr44XBCg4CdBKKS0hpuBtFiSeYz9U9hn1L+lKN 6NTTRIcAMHPZCRv8PJ8C0yFoWydFa7u2hQ6+g93kD6oJsWEGNDDlDLVFLSSYabsAjK7V bZsfO4vYk0POpljQRMg6WvYRuGFmJhmoD89sZK8IIPVq2XqlKX36B0VN4Sb+he2r/ge/ VtXUFKS21QKEAsO5W/xX0gtWqUlc1x9JiDe55+6/hbmFLinGbe2a1t+Dp5/cZOLE84eO PSYjHe5kRLIbxtOcwTWbP2x/ITjOe2a/9T/rL3mc9gs1+RDU3oPRmshiXFsCrD6jki+s WkwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782313952; x=1782918752; 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=r4Rgqs0dmpAmBtoUIzRDi3XnAOaTZ7bU1jnGrXxRY7M=; b=rjvm7Ac16F83eJcf6/7uKYw6sTsbjnkF9Sc2xTYef8/GjXrlj+T0Zkb5ey9N8AhYq5 cHPto5XAdB/LtAnM2sIzmWsTh4Moc3rmXB6cYgSZirY9ct6cVH44vhAUeVtennJ4wIaT 1JP25ALvUSeFMi5YmiVcR6dnIfOkSd6/gbIYRZTxY13RUsfw3+yyZnPu1QF+APw+4IFK kSjhFA4kjlPFJIHWGHHiGHH5m0wsQ2n8wbNh8HAtF+jPHfHISYF0cusViNVXUAgPLC49 ta2GXjJ4u9EOJde/OYChX64/0XwFIU3iQ2GF5oxkiwL3bjahdv/WKctxBy/20KFzMb+H s+1w== X-Forwarded-Encrypted: i=1; AFNElJ9ePl5vqgdqo+vkk5+UhEQnJ51X8Za/gAnSGkYN7IynKQQNQ54PeGLggtkVxPIFrJ4c7lqJVqn779E=@vger.kernel.org X-Gm-Message-State: AOJu0Yxp0WAEhi1SVw89UrG/90TlVsiLyKXKAeT90O9otuVLLhTLSy1C Rv7wQjm/pbqufcjDKUzbrYKzKUAO1cyO9mn+OabcMwAp/FJFGxqLjX3C7+0OZIggU/h+Ep9co5u BdouZ3w== X-Received: from pfbjj5.prod.google.com ([2002:a05:6a00:93a5:b0:842:507a:6d57]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a00:b4a:b0:843:49f0:f5a0 with SMTP id d2e1a72fcca58-845a2caa198mr4791522b3a.32.1782313951462; Wed, 24 Jun 2026 08:12:31 -0700 (PDT) Date: Wed, 24 Jun 2026 08:12:30 -0700 In-Reply-To: Precedence: bulk X-Mailing-List: linux-doc@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260618-gmem-inplace-conversion-v8-0-9d2959357853@google.com> <20260618-gmem-inplace-conversion-v8-4-9d2959357853@google.com> Message-ID: Subject: Re: [PATCH v8 04/46] KVM: Decouple kvm_has_arch_private_mem from CONFIG_KVM_VM_MEMORY_ATTRIBUTES From: Sean Christopherson To: Ackerley Tng Cc: Binbin Wu , 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 , 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 Content-Type: text/plain; charset="us-ascii" On Tue, Jun 23, 2026, Ackerley Tng wrote: > Binbin Wu writes: > > > On 6/19/2026 8:31 AM, Ackerley Tng via B4 Relay wrote: > >> From: Sean Christopherson > >> > >> When memory attributes become trackable in guest_memfd, the concept of > >> having private memory is no longer dependent on > >> CONFIG_KVM_VM_MEMORY_ATTRIBUTES. > >> > >> With this, on x86, kvm_arch_has_private_mem() is defined if some CoCo > >> platform support (or the testing CONFIG_KVM_SW_PROTECTED_VM) is compiled > >> in. > >> > >> Signed-off-by: Sean Christopherson > >> Co-developed-by: Ackerley Tng > >> Signed-off-by: Ackerley Tng > > > > Reviewed-by: Binbin Wu > > > > One nit below. > > > >> --- > >> arch/x86/include/asm/kvm_host.h | 4 +++- > >> include/linux/kvm_host.h | 2 +- > >> 2 files changed, 4 insertions(+), 2 deletions(-) > >> > >> diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h > >> index 8e8eb8a5e8a6b..1bde67cf6eb0e 100644 > >> --- a/arch/x86/include/asm/kvm_host.h > >> +++ b/arch/x86/include/asm/kvm_host.h > >> @@ -2394,7 +2394,9 @@ void kvm_configure_mmu(bool enable_tdp, int tdp_forced_root_level, > >> int tdp_max_root_level, int tdp_huge_page_level); > >> > >> > >> -#ifdef CONFIG_KVM_VM_MEMORY_ATTRIBUTES > >> +#if defined(CONFIG_KVM_SW_PROTECTED_VM) || \ > >> + defined(CONFIG_KVM_INTEL_TDX) || \ > >> + defined(CONFIG_KVM_AMD_SEV) > > > > Nit: > > Vertically align the defined(XXX) statements for better readability? > > > > Sean had this aligned with spaces, and checkpatch complained about checkpatch is a tool, it is neither omniscient nor authoritative. And for things like this, the *entire* purpose for rules/guildlines like "no tabs after spaces" is to help ensure the code is easier to read, e.g. doesn't end up with wonky formatting when viewed in certain editors or whatever. So, ignore checkpatch if it complains about formatting that is visually superior to what makes checkpatch happy. > having no spaces before tabs, so I switched it to tabs instead since I > don't think alignment like that is officially documented either way. This exact case may not be "officially" documented, but the general gist is in Documentation/process/maintainer-tip.rst: When splitting function declarations or function calls, then please align the first argument in the second line with the first argument in the first line:: And there is lots and lots of prior art on-list (from me and others) that is more or less as good as official documentation. > Either way is fine :) Please restore the alignment.