Re: [PATCH v7 05/22] x86/sev: Move GHCB page based HV communication out of startup code

Ard Biesheuvel
2025-08-31T12:30:42Z

On Sun, 31 Aug 2025 at 13:15, Borislav Petkov <bp@alien8.de> wrote:
>
> On Sun, Aug 31, 2025 at 12:56:41PM +0200, Ard Biesheuvel wrote:
> > 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.
>
> The real question is - and I'm sceptical - whether the startup code runs too
> early for boot_cpu_has(). And how is the startup code going to call
> boot_cpu_has().
>
> /me builds .s
>
> Aha, so it gets converted into a boot_cpu_data access:
>
> # arch/x86/boot/startup/sev-shared.c:662: if (validate && !has_cpuflag(X86_FEATURE_COHERENCY_SFW_NO))
> testb %r13b, %r13b # validate
> je .L46 #,
> # ./arch/x86/include/asm/bitops.h:206: (addr[nr >> _BITOPS_LONG_SHIFT])) != 0;
> movq 80+boot_cpu_data(%rip), %rax # MEM[(const volatile long unsigned int *)&boot_cpu_data + 80B], _15
> # arch/x86/boot/startup/sev-shared.c:662: if (validate && !has_cpuflag(X86_FEATURE_COHERENCY_SFW_NO))
>
> But former question remains: AFAIK, you want to run the startup code waaay
> earlier, before we do identify_boot_cpu() which prepares boot_cpu_data, right?
>

I suppose that in this particular case, things work out fine because
calling sev_evict_cache() unnecessarily is harmless. But I agree that
in general, relying on CPU flags in code that may be called this early
is not great.

Perhaps this conditional should be moved into the caller instead
(early_set_pages_state()), and early callers from inside the startup
code should call sev_evict_cache() unconditionally?