On Thu, 12 Jan 2023 at 10:56, Michael Brown <mc...@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? -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#98353): https://edk2.groups.io/g/devel/message/98353 Mute This Topic: https://groups.io/mt/96218818/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
