On 1/18/23 14:10, Ard Biesheuvel wrote: > 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. >
yes. -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#98806): https://edk2.groups.io/g/devel/message/98806 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] -=-=-=-=-=-=-=-=-=-=-=-
