smbios: in case of entry point is 'auto' try to build v2 tables 1st
commit4840c8a2b4666cf1b320a387c3f8b609258e7654
authorIgor Mammedov <imammedo@redhat.com>
Thu, 14 Mar 2024 15:22:57 +0000 (14 16:22 +0100)
committerMichael S. Tsirkin <mst@redhat.com>
Mon, 18 Mar 2024 12:42:46 +0000 (18 08:42 -0400)
treeeec5a29513382721d090aaab3336f66bf6169657
parent4901b80e13be62fc8ea2d8844941f336076af266
smbios: in case of entry point is 'auto' try to build v2 tables 1st

QEMU for some time now uses SMBIOS 3.0 for PC/Q35 machines by
default, however Windows has a bug in locating SMBIOS 3.0
entrypoint and fails to find tables when booted on SeaBIOS
(on UEFI SMBIOS 3.0 tables work fine since firmware hands
over tables in another way)

Missing SMBIOS tables may lead to some issues for guest
though (worst are: possible reactiveation, inability to
get virtio drivers from 'Windows Update')

It's unclear  at this point if MS will fix the issue on their
side. So instead of it (or rather in addition) this patch
will try to workaround the issue.

aka, use smbios-entry-point-type=auto to make QEMU try
generating conservative SMBIOS 2.0 tables and if that
fails (due to limits/requested configuration) fallback
to SMBIOS 3.0 tables.

With this in place majority of users will use SMBIOS 2.0
tables which work fine with (Windows + legacy BIOS).
The configurations that is not to possible to describe
with SMBIOS 2.0 will switch automatically to SMBIOS 3.0
(which will trigger Windows bug but there is nothing
QEMU can do here, so go and aks Microsoft to real fix).

Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Reviewed-by: Ani Sinha <anisinha@redhat.com>
Tested-by: Fiona Ebner <f.ebner@proxmox.com>
Message-Id: <20240314152302.2324164-17-imammedo@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
hw/smbios/smbios.c