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

["Ard Biesheuvel" <ardb@kernel.org>]

On Wed, 18 Jan 2023 at 12:50, Laszlo Ersek <lersek@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 <kraxel@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.