Re: [edk2-devel] [PATCH v2] OvmfPkg/PlatformInitLib: catch QEMU's CPU hotplug reg block regression

["Ard Biesheuvel" <ardb@kernel.org>]

On Thu, 12 Jan 2023 at 10:56, Michael Brown <mcb30@ipxe.org> wrote:
>
> On 12/01/2023 08:28, Laszlo Ersek wrote:
> > In QEMU v5.1.0, the CPU hotplug register block misbehaves: the negotiation
> > protocol is (effectively) broken such that it suggests that switching from
> > the legacy interface to the modern interface works, but in reality the
> > switch never happens. The symptom has been witnessed when using TCG
> > acceleration; KVM seems to mask the issue. The issue persists with the
> > following (latest) stable QEMU releases: v5.2.0, v6.2.0, v7.2.0. Currently
> > there is no stable release that addresses the problem.
> >
> > The QEMU bug confuses the Present and Possible counting in function
> > PlatformMaxCpuCountInitialization(), in
> > "OvmfPkg/Library/PlatformInitLib/Platform.c". OVMF ends up with Present=0
> > Possible=1. This in turn further confuses MpInitLib in UefiCpuPkg (hence
> > firmware-time multiprocessing will be broken). Worse, CPU hot(un)plug with
> > SMI will be summarily broken in OvmfPkg/CpuHotplugSmm, which (considering
> > the privilege level of SMM) is not that great.
> >
> > Detect the issue in PlatformMaxCpuCountInitialization(), and print an
> > error message and *hang* if the issue is present.
>
> Would this mean that OVMF would refuse to start with all current distro
> versions of qemu (when not using KVM), or am I misunderstanding?
>

I had the same question, actually. This would be less than ideal,
especially given the fact that I didn't even notice the breakage, and
Linux happily booted on all cores.

If this is a security issue that affects SMM, could we make this
behavior dependent on REQUIRE_SMM perhaps?