[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMj1kXEQghhi4qCdV6PrYK-mTYFu5yVcn3fEOSZsC6vR7TiMEg@mail.gmail.com>
Date: Sun, 31 Aug 2025 12:56:41 +0200
From: Ard Biesheuvel <ardb@...nel.org>
To: Borislav Petkov <bp@...en8.de>
Cc: Ard Biesheuvel <ardb+git@...gle.com>, linux-kernel@...r.kernel.org,
linux-efi@...r.kernel.org, x86@...nel.org, Ingo Molnar <mingo@...nel.org>,
Kevin Loughlin <kevinloughlin@...gle.com>, Tom Lendacky <thomas.lendacky@....com>,
Josh Poimboeuf <jpoimboe@...nel.org>, Peter Zijlstra <peterz@...radead.org>,
Nikunj A Dadhania <nikunj@....com>
Subject: Re: [PATCH v7 05/22] x86/sev: Move GHCB page based HV communication
out of startup code
On Sun, 31 Aug 2025 at 12:52, Ard Biesheuvel <ardb@...nel.org> wrote:
>
> On Sun, 31 Aug 2025 at 12:50, Borislav Petkov <bp@...en8.de> wrote:
> >
> > On Thu, Aug 28, 2025 at 12:22:08PM +0200, Ard Biesheuvel wrote:
> > > diff --git a/arch/x86/boot/startup/sev-shared.c b/arch/x86/boot/startup/sev-shared.c
> > > index 83c222a4f1fa..24cbeaf7ff4f 100644
> > > --- a/arch/x86/boot/startup/sev-shared.c
> > > +++ b/arch/x86/boot/startup/sev-shared.c
> > > @@ -13,12 +13,9 @@
> > >
> > > #ifndef __BOOT_COMPRESSED
> > > #define error(v) pr_err(v)
> > > -#define has_cpuflag(f) boot_cpu_has(f)
> >
> > In file included from arch/x86/boot/startup/sev-startup.c:106:
> > arch/x86/boot/startup/sev-shared.c: In function ‘pvalidate_4k_page’:
> > arch/x86/boot/startup/sev-shared.c:661:26: error: implicit declaration of function ‘has_cpuflag’ [-Wimplicit-function-declaration]
> > 661 | if (validate && !has_cpuflag(X86_FEATURE_COHERENCY_SFW_NO))
> > | ^~~~~~~~~~~
> > make[3]: *** [scripts/Makefile.build:287: arch/x86/boot/startup/sev-startup.o] Error 1
> > make[2]: *** [scripts/Makefile.build:556: arch/x86/boot/startup] Error 2
> > make[2]: *** Waiting for unfinished jobs....
> > make[1]: *** [/mnt/kernel/kernel/linux/Makefile:2011: .] Error 2
> > make: *** [Makefile:248: __sub-make] Error 2
> >
> > We probably will have to use the CPUID MSR protocol thing here or so...
> >
>
> Huh I thought I had fixed that: we can just keep that has_cpuflag()
> definition if there is a need for it.
OK it appears I've fixed it in the wrong place: the next patch adds
back the definition of has_cpuflag() so I squashed that hunk into the
wrong patch, it seems.
Powered by blists - more mailing lists