Received-SPF: pass (google.com: domain of linux-kernel+bounces-51271-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1;
Date: Sat, 3 Feb 2024 12:35:52 -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: <20240203193552.GA655765@dev-fedora.aadp>
References: <20240202-provide-cc_vendor-without-arch_has_cc_platform-v1-1-09ad5f2a3099@kernel.org>
 <20240203102925.GFZb4VhT1IwX-XRxTV@fat_crate.local>
 <20240203160806.GA520926@dev-fedora.aadp>
 <20240203190729.GHZb6O8UborcetShlw@fat_crate.local>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20240203190729.GHZb6O8UborcetShlw@fat_crate.local>

On Sat, Feb 03, 2024 at 08:07:29PM +0100, Borislav Petkov wrote:
> On Sat, Feb 03, 2024 at 09:08:06AM -0700, Nathan Chancellor wrote:
> > 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.
> 
> I guess I wasn't clear enough, sorry about that. Of the two, that one

Guess that makes both of us :)

> should be in Fixes which is the first one which causes the build issue
> so that the fix can be backported to the respective kernels.
> 
> IOW, if you can't trigger with da86eb961184, then a9ef277488cf should be
> in Fixes and your fix should go through the KVM tree, along with
> a9ef277488cf.
> 
> How does that sound?

Yeah, that seems like a fair plan to me. I was a little concerned about
a future change that would require backporting to kernels that have
da86eb961184 (i.e., 6.6) that do not have a9ef277488cf and miss this fix
but that is a bridge that can be crossed if it ever appears, no point in
thinking too hard about it at this point.

I can send a v2 on Monday, unless Paolo wants to just add

Fixes: a9ef277488cf ("x86/kvm: Fix SEV check in sev_map_percpu_data()")

directly during application. I think the rest of the patch is fine but
if there are any other changes that should be made, I am more than happy
do to so.

Cheers,
Nathan