Re: [PATCH v2 2/3] firmware: coreboot: loader for Linux-owned SMI handler

[Michal Gorlas <michal.gorlas@9elements.com>]

On Fri, Jun 27, 2025 at 02:49:21AM +0000, Tzung-Bi Shih wrote:
> On Thu, Jun 26, 2025 at 01:41:45PM +0200, Michal Gorlas wrote:
> > On Wed, Jun 25, 2025 at 02:26:11PM +0200, Michal Gorlas wrote:
> > > > > +
> > > > > +	/*
> > > > > +	 * Gives SMI some time in case it takes longer than expected.
> > > > > +	 * Only useful on real hardware (tested on RaptorLake), not needed on emulation.
> > > > > +	 */
> > > > > +	mdelay(100);
> > > > 
> > > > This looks weird. Are there some ways for Linux to be aware of the SMI has
> > > > completed?
> > > 
> > > Not in a straight forward fashion. On Intel SoCs we could read MSR_SMI_COUNT
> > > [1] before and after sending an SMI, and wait till it increments. I am
> > > not aware about any unified way that works for AMD SoCs. However, so far
> > > none of the AMD boards supported by coreboot was tested with MM payload,
> > > so to make it Intel-only in v3 is not a bad idea.
> > > 
> > > [1]: https://elixir.bootlin.com/linux/v6.16-rc3/source/arch/x86/include/asm/msr-index.h#L880
> > 
> > As a follow-up here, making COREBOOT_PAYLOAD_MM dependent on !SMP
> > resolves the need of acknowledging SMI completion. If SMI takes longer,
> > Linux is just stalled until SMI handler gives the CPU back to the caller.
> > I think for this case it could be the way, LinuxBoot is by default
> > compiled without SMP support anyways when used as coreboot's payload [1],
> > [2].
> > 
> > [1]: https://github.com/coreboot/coreboot/blob/main/payloads/external/LinuxBoot/x86_64/defconfig
> > [2]: https://github.com/coreboot/coreboot/blob/main/payloads/external/LinuxBoot/i386/defconfig
> 
> To make sure I understand: do you mean the trigger_smi() becomes a blocking
> call without a timeout?

Short answer: potentially yes. Longer answer:

 "mov	%[apmc_port], %%dx\n\t"
 "outb	%%al, %%dx\n\t"

in trigger_smi() will switch CPU context to SMM, meaning, current state
is saved and CPU starts executing whatever instructions are under the
address stored under SMBASE register. At this point, Linux has no control
over that CPU, which can cause chaos, particulary on real hardware.
I am not an expert on how the scheduler is implemented, but I can imagine
it will assign next not-blocked CPU to execute the instructions coming
after trigger_smi(), while SMI is still being handled on other CPU.

> 
> I may misunderstand: depends on !SMP which also means it can't use on most
> modern architectures.

Not necessarily. This driver is useful only if Linux is used to be
coreboot payload (aka LinuxBoot). As far as I know there is no real need
to have SMP enabled there, sole responsibility of the LinuxBoot is to
bring-up remaining hardware (similar to Driver Execution Environment (DXE)
responsibilities when booting with UEFI), and kexec to the OS kernel,
which is likely built with SMP.