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

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

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?

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.