Received-SPF: pass (google.com: domain of linux-kernel+bounces-51176-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Date: Sat, 3 Feb 2024 09:08:06 -0700
From: Nathan Chancellor <nathan@kernel.org>
To: Borislav Petkov <bp@alien8.de>
Cc: pbonzini@redhat.com, tglx@linutronix.de, mingo@redhat.com,
	dave.hansen@linux.intel.com, x86@kernel.org,
	kirill.shutemov@linux.intel.com, ndesaulniers@google.com,
	morbo@google.com, justinstitt@google.com,
	linux-kernel@vger.kernel.org, llvm@lists.linux.dev,
	patches@lists.linux.dev
Subject: Re: [PATCH] x86/coco: Define cc_vendor without
 CONFIG_ARCH_HAS_CC_PLATFORM
Message-ID: <20240203160806.GA520926@dev-fedora.aadp>
References: <20240202-provide-cc_vendor-without-arch_has_cc_platform-v1-1-09ad5f2a3099@kernel.org>
 <20240203102925.GFZb4VhT1IwX-XRxTV@fat_crate.local>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20240203102925.GFZb4VhT1IwX-XRxTV@fat_crate.local>

On Sat, Feb 03, 2024 at 11:29:25AM +0100, Borislav Petkov wrote:
> On Fri, Feb 02, 2024 at 04:53:21PM -0700, Nathan Chancellor wrote:
> > Commit a9ef277488cf ("x86/kvm: Fix SEV check in sev_map_percpu_data()")
> > exposes this build error but I think it is really a problem with commit
> > da86eb961184 ("x86/coco: Get rid of accessor functions"), although I am
> > not positive so I left out the fixes tag.
> 
> Well, which is it?

Perhaps I should have expanded more on this in the commit message or
trailer.

> If you're running those GCOV LLVM tests regularly and you haven't seen
> it after da86eb961184, then it cannot be that one, can it?

Well the issue is that at da86eb961184, all uses of cc_vendor is in code
that is guarded by either CONFIG_AMD_MEM_ENCRYPT or
CONFIG_INTEL_TDX_GUEST, which both select CONFIG_ARCH_HAS_CC_PLATFORM,
so this build error cannot happen at that revision.

$ git grep cc_vendor da86eb961184
da86eb961184:arch/x86/coco/core.c:enum cc_vendor cc_vendor __ro_after_init = CC_VENDOR_NONE;
da86eb961184:arch/x86/coco/core.c:        switch (cc_vendor) {
da86eb961184:arch/x86/coco/core.c:        switch (cc_vendor) {
da86eb961184:arch/x86/coco/core.c:        switch (cc_vendor) {
da86eb961184:arch/x86/coco/tdx/tdx.c:        cc_vendor = CC_VENDOR_INTEL;
da86eb961184:arch/x86/hyperv/ivm.c:        cc_vendor = CC_VENDOR_AMD;
da86eb961184:arch/x86/include/asm/coco.h:enum cc_vendor {
da86eb961184:arch/x86/include/asm/coco.h:extern enum cc_vendor cc_vendor;
da86eb961184:arch/x86/include/asm/sev.h:        if (cc_vendor == CC_VENDOR_AMD &&
da86eb961184:arch/x86/include/asm/sev.h:        if (cc_vendor == CC_VENDOR_AMD &&
da86eb961184:arch/x86/include/asm/sev.h:        if (cc_vendor == CC_VENDOR_AMD &&
da86eb961184:arch/x86/mm/mem_encrypt_identity.c:                cc_vendor = CC_VENDOR_AMD;

However, is it really a9ef277488cf's fault that it happened to use
cc_vendor in generic code where those same conditions may or may not
satisfied? If it had used cc_get_vendor() instead if da86eb961184 had
not existed, this issue would not have happened.

I have no issues with blaming a9ef277488cf but I think da86eb961184 is
equally blamable for removing the option to use cc_vendor in generic x86
code where CONFIG_ARCH_HAS_CC_PLATFORM may not be set. Hopefully that at
least carifies the "which is it?" question, I'll do whatever you think
is best.

Cheers,
Nathan