On 1/18/23 08:25, Gerd Hoffmann wrote: > On Tue, Jan 17, 2023 at 05:43:53PM +0100, Ard Biesheuvel wrote: >> On Tue, 17 Jan 2023 at 13:37, Gerd Hoffmann <kra...@redhat.com> wrote: >>> >>> Hi, >>> >>>>>> In particular the firmware makes no further decisions based on >>>>>> whether QEMU advertized some of these features. >>>>> >>>>> I was thinking the other way around: When cpu hotplug is disabled in >>>>> qemu it should be safe to skip the whole cpu hotplug checking dance. >>>>> See test patch below. >>>>> >>>>> That would give us a config switch (turn off cpu hotplug support) >>>>> which would allow edk2 run on qemu versions with broken cpu hotplug. >>>>> >>>>> Does the idea look sane or do I miss something? >>> >>>> This would be wrong. >>>> >>>> [ detailed description snipped here (but stored for later reference, >>>> thanks for all the details) ] >>> >>> So, the tl;dr version: cpu hotplug is older than smi feature >>> negotiation, so smi hotplug feature bit being off doesn't imply >>> qemu wouldn't hotplug cpus. >>> >>> So, no easy way out. Luckily this affects tcg only. >>> >>> For edk2 ci doing (tcg) efi shell test boots switching to Oliver's >>> latest containers with fixed qemu included should handle things >>> (latest series just posted). So once this is in we should be able to >>> merge this patch without breaking CI. >> >> My head is spinning. >> >> What about running QEMU with only a single CPU, and without any of >> these features? Is there really no way we can make that work without >> turning OVMF into the timebomb that Laszlo describes? > > I can't see any way :( > > ovmf seeing only a single cpu does not imply cpu hotplug can't happen, > it could be "qemu -smp cpus=1,maxcpus=4". Figuring the maxcpus number > depends on the broken cpu hotplug registers. > >> It's just very annoying that on a non-KVM host and a given QEMU >> binary, you might simply be out of luck entirely, and there is no way >> you can run OVMF with the fix applied. I would like to avoid that if >> possible. > > Indeed.
... you could introduce a new fw_cfg boolean switch (and explain it in the hang message) that meant: "I know what this QEMU bug is, I understand its consequences are obscure, risky, and far-reaching in OVMF, I've been warned, I know what I'm doing". That's a relatively small addition to this patch, and then the risk is assumed by the user. It resolves "being out of luck *entirely*". Laszlo -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#98797): https://edk2.groups.io/g/devel/message/98797 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] -=-=-=-=-=-=-=-=-=-=-=-
