Re: [edk2-devel] [PATCH 0/1] OvmfPkg/Bhyve: QemuFwCfg support

["Gerd Hoffmann" <kraxel@redhat.com>]

On Tue, Mar 29, 2022 at 09:57:40AM +0000, Corvin Köhne wrote:
> Hi Gerd,
> 
> > There is FW_CFG_NB_CPUS + FW_CFG_MAX_CPUS.  ovmf uses different names,
> > see OvmfPkg/Include/IndustryStandard/QemuFwCfg.h
> >
> > PlatformPei for qemu uses QemuFwCfgItemSmpCpuCount aka FW_CFG_NB_CPUS,
> > which is the number of cpus which are online.
> >
> > I think FW_CFG_MAX_CPUS is basically unused these days.  It played a
> > role back when seabios created the acpi tables for cpu hotplug as
> > described in the comment above.  In qemu 2.0 & newer the acpi tables are
> > generated by qemu instead.  The firmware just downloads them from fw_cfg
> > and installs them for the OS, it doesn't need to know virtual machine
> > configuration details any more.
> 
> The FwCfgItem of this patch is used by bhyve to build the MADT. So, it's
> similar to the use case of FW_CFG_MAX_CPUS. At the moment, I'm using
> an additional bhyve specific FwCfgItem. I just want to ask, if it makes sense
> to use FW_CFG_MAX_CPUS to avoid two items for the same purpose or to
> keep it as is.

Given that FW_CFG_MAX_CPUS is unused on qemu these days it is unlikely
that reusing it causes problems.  IIRC the problems mentioned in the
comment only matter with VMs having > 255 vCPUs because somewhere only
one byte was used for the cpu / apic index.

But I think I'd tend to keep the bhyve-specific behavior nevertheless,
so you don't have to worry about qemu quirks.

Or go the qemu route and generate the acpi tables on the host instead.
When you generate the acpi tables in the guest firmware you always have
the problem that you need to pass all the virtual machine configuration
information needed to generate the tables to the firmware.  The
information needed changes over time when new features are added, which
requires protocol updates, which in turn requires lockstep updates of
hypervisor and firmware to deploy the new features ...

HTH & take care,
  Gerd