On Wed, 18 Jan 2023 at 12:50, Laszlo Ersek <ler...@redhat.com> wrote: > > 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*". >
You mean the kind of fw_cfg vairiable that is arbitrarily settable from the QEMU command line, right? Yeah, that would at least provide a way out. -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#98805): https://edk2.groups.io/g/devel/message/98805 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] -=-=-=-=-=-=-=-=-=-=-=-
