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

["Laszlo Ersek" <lersek@redhat.com>]

On 1/12/23 11:09, Ard Biesheuvel wrote:
> 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?

Yes, we could restrict this with FeaturePcdGet (PcdSmmSmramRequire), but
then all multi-processing (the MP PPI from CpuMpPei, and the MP protocol
from CpuDxe) remains broken (or at least "misconfigured") in OVMF.

That can have OS visible effects; for example, MSR_IA32_FEATURE_CONTROL
is supposed to be configured identically on all processors, and
PlatformPei uses the MP PPI (from CpuMpPei) to do that;
<https://tianocore.acgmultimedia.com/show_bug.cgi?id=86>.

Is it common that people run bleeding edge OVMF (built from git
checkout) on distro QEMU?

Edk2's release cycle is much shorter than QEMU's, so I guess we should
delay merging this until after QEMU v8 is out, at the least. But, if
there won't be another stable release for, say, QEMU v6, is that reason
enough to abandon this patch in OVMF?

Laszlo