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 C3A9A27587D 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-8454912a507so2040177b3a.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=IWGrnjw1vV6m2LOLI+5/cXV3j9sDpqVhily/7v8Si7hu5LrNG70kiMv3c4O3VdxJKi spzQjidsReLaC51j3VS+r69fsYASiPycsf1Kv3fYfgRcSa9vGQZ4TwbRJ2bBZ4qa4hS6 Eagz3lNWRMu0tprEx5+18vTF2CrAsmbmzFS+9r38m2azwv1MYBH2xDrjQJgBNJ1wXxXA fSMnGeGmmrhqIddghjPZOezgV1qQd9SGy1f0TwNTG8RAR/Z2PQ4l8hbVfBM/ffWcg6rr wcUB7cfabK64VAZZJ2cwNbGjbJQPgWvGZGLmpB+bxLw098/TpTmonXCKHkl1oiM7l7sL nV0g== X-Forwarded-Encrypted: i=1; AFNElJ9vSZjxkygxkQrTgW//fobJ/AfEtsJpwF7TVePZexoj5tntIurZ0XtWeDcA3VbDYOkh3WYbDWDv3Nm3480=@vger.kernel.org X-Gm-Message-State: AOJu0YyX1Okn4te0WtY4ZIAv7H+yMfJpQ+IeEP2090fNa2xDLXxDScXk LL8NJwhAbHQUn3CWbx+6iRsXhjqum1wmrRP6kSW+658fBYyLmTch8UEeudyyHU3jJDMzYl3+w2p m+rXarQ== 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-kernel@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.