| Message ID | 20240227154749.1818189-1-imammedo@redhat.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Workaround Windows failing to find 64bit SMBIOS entry point with SeaBIOS | expand |
On Tue, Feb 27, 2024 at 04:47:30PM +0100, Igor Mammedov wrote: > Windows (10) bootloader when running on top of SeaBIOS, fails to find > SMBIOSv3 entry point. Tracing it shows that it looks for v2 anchor markers > only and not v3. Tricking it into believing that entry point is found > lets Windows successfully locate and parse SMBIOSv3 tables. Whether it > will be fixed on Windows side is not clear so here goes a workaround. > > Idea is to try build v2 tables if QEMU configuration permits, > and fallback to v3 tables otherwise. That will mask Windows issue > form majority of users. > However if VM configuration can't be described (typically large VMs) > by v2 tables, QEMU will use SMBIOSv3 and Windows will hit the issue > again. In this case complain to Microsoft and/or use UEFI instead of > SeaBIOS (requires reinstall). Sounds like the best we can do. > Default compat setting of smbios-entry-point-type after series > for pc/q35 machines: > * 9.0-newer: 'auto' > * 8.1-8.2: '64' > * 8.0-older: '32' > > Fixes: https://gitlab.com/qemu-project/qemu/-/issues/2008 > CC: peter.maydell@linaro.org > CC: pbonzini@redhat.com > CC: mst@redhat.com > CC: gaosong@loongson.cn > CC: alistair.francis@wdc.com > CC: palmer@dabbelt.com > CC: bin.meng@windriver.com > CC: liwei1518@gmail.com > CC: dbarboza@ventanamicro.com > CC: zhiwei_liu@linux.alibaba.com > CC: imammedo@redhat.com > CC: anisinha@redhat.com > CC: philmd@linaro.org > CC: wangyanan55@huawei.com > CC: eblake@redhat.com > CC: armbru@redhat.com > CC: qemu-arm@nongnu.org > CC: qemu-riscv@nongnu.org > CC: f.ebner@proxmox.com > > Igor Mammedov (19): > tests: smbios: make it possible to write SMBIOS only test > tests: smbios: add test for -smbios type=11 option > tests: smbios: add test for legacy mode CLI options > smbios: cleanup smbios_get_tables() from legacy handling > smbios: get rid of smbios_smp_sockets global > smbios: get rid of smbios_legacy global > smbios: avoid mangling user provided tables > smbios: don't check type4 structures in legacy mode > smbios: build legacy mode code only for 'pc' machine > smbios: handle errors consistently > smbios: clear smbios_tables pointer after freeing > get rid of global smbios_ep_type > smbios: extend smbios-entry-point-type with 'auto' value > smbios: in case of entry point is 'auto' try to build v2 tables 1st > smbios: error out when building type 4 table is not possible > smbios: clear smbios_type4_count before building tables > tests: acpi/smbios: whitelist expected blobs > pc/q35: set SMBIOS entry point type to 'auto' by default > tests: acpi: update expected SSDT.dimmpxm blob > > hw/i386/fw_cfg.h | 3 +- > include/hw/firmware/smbios.h | 29 +- > hw/arm/virt.c | 6 +- > hw/i386/Kconfig | 1 + > hw/i386/fw_cfg.c | 14 +- > hw/i386/pc.c | 4 +- > hw/i386/pc_piix.c | 4 + > hw/i386/pc_q35.c | 3 + > hw/loongarch/virt.c | 7 +- > hw/riscv/virt.c | 6 +- > hw/smbios/Kconfig | 2 + > hw/smbios/meson.build | 4 + > hw/smbios/smbios.c | 481 +++++++++++---------------- > hw/smbios/smbios_legacy.c | 185 +++++++++++ > hw/smbios/smbios_legacy_stub.c | 16 + > qapi/machine.json | 5 +- > tests/data/acpi/q35/SSDT.dimmpxm | Bin 1815 -> 1815 bytes > tests/data/smbios/type11_blob | Bin 0 -> 11 bytes > tests/data/smbios/type11_blob.legacy | Bin 0 -> 10 bytes > tests/qtest/bios-tables-test.c | 81 ++++- > 20 files changed, 535 insertions(+), 316 deletions(-) > create mode 100644 hw/smbios/smbios_legacy.c > create mode 100644 hw/smbios/smbios_legacy_stub.c > create mode 100644 tests/data/smbios/type11_blob > create mode 100644 tests/data/smbios/type11_blob.legacy > > -- > 2.39.3
Am 27.02.24 um 16:47 schrieb Igor Mammedov: > Windows (10) bootloader when running on top of SeaBIOS, fails to find > SMBIOSv3 entry point. Tracing it shows that it looks for v2 anchor markers > only and not v3. Tricking it into believing that entry point is found > lets Windows successfully locate and parse SMBIOSv3 tables. Whether it > will be fixed on Windows side is not clear so here goes a workaround. > > Idea is to try build v2 tables if QEMU configuration permits, > and fallback to v3 tables otherwise. That will mask Windows issue > form majority of users. > However if VM configuration can't be described (typically large VMs) > by v2 tables, QEMU will use SMBIOSv3 and Windows will hit the issue > again. In this case complain to Microsoft and/or use UEFI instead of > SeaBIOS (requires reinstall). > > Default compat setting of smbios-entry-point-type after series > for pc/q35 machines: > * 9.0-newer: 'auto' > * 8.1-8.2: '64' > * 8.0-older: '32' > > Fixes: https://gitlab.com/qemu-project/qemu/-/issues/2008 Thank you! I'm happy to confirm that this series works around the issue :) Best Regards, Fiona
Am 29.02.24 um 14:18 schrieb Fiona Ebner: > Am 27.02.24 um 16:47 schrieb Igor Mammedov: >> Windows (10) bootloader when running on top of SeaBIOS, fails to find >> SMBIOSv3 entry point. Tracing it shows that it looks for v2 anchor markers >> only and not v3. Tricking it into believing that entry point is found >> lets Windows successfully locate and parse SMBIOSv3 tables. Whether it >> will be fixed on Windows side is not clear so here goes a workaround. >> >> Idea is to try build v2 tables if QEMU configuration permits, >> and fallback to v3 tables otherwise. That will mask Windows issue >> form majority of users. >> However if VM configuration can't be described (typically large VMs) >> by v2 tables, QEMU will use SMBIOSv3 and Windows will hit the issue >> again. In this case complain to Microsoft and/or use UEFI instead of >> SeaBIOS (requires reinstall). >> >> Default compat setting of smbios-entry-point-type after series >> for pc/q35 machines: >> * 9.0-newer: 'auto' >> * 8.1-8.2: '64' >> * 8.0-older: '32' >> >> Fixes: https://gitlab.com/qemu-project/qemu/-/issues/2008 > > Thank you! I'm happy to confirm that this series works around the issue :) > While I still didn't do any in-depth testing (don't have enough knowledge for that anyways), I played around a bit more now, check that nothing obvious breaks also with a Linux VM and also ran a successful 'make check'. If that is enough, feel free to add: Tested-by: Fiona Ebner <f.ebner@proxmox.com> Best Regards, Fiona
On Tue, Feb 27, 2024 at 04:47:30PM +0100, Igor Mammedov wrote: > Windows (10) bootloader when running on top of SeaBIOS, fails to find > SMBIOSv3 entry point. Tracing it shows that it looks for v2 anchor markers > only and not v3. Tricking it into believing that entry point is found > lets Windows successfully locate and parse SMBIOSv3 tables. Whether it > will be fixed on Windows side is not clear so here goes a workaround. > > Idea is to try build v2 tables if QEMU configuration permits, > and fallback to v3 tables otherwise. That will mask Windows issue > form majority of users. > However if VM configuration can't be described (typically large VMs) > by v2 tables, QEMU will use SMBIOSv3 and Windows will hit the issue > again. In this case complain to Microsoft and/or use UEFI instead of > SeaBIOS (requires reinstall). Igor so you want to repost a version with a couple of patches squashed? > Default compat setting of smbios-entry-point-type after series > for pc/q35 machines: > * 9.0-newer: 'auto' > * 8.1-8.2: '64' > * 8.0-older: '32' > > Fixes: https://gitlab.com/qemu-project/qemu/-/issues/2008 > CC: peter.maydell@linaro.org > CC: pbonzini@redhat.com > CC: mst@redhat.com > CC: gaosong@loongson.cn > CC: alistair.francis@wdc.com > CC: palmer@dabbelt.com > CC: bin.meng@windriver.com > CC: liwei1518@gmail.com > CC: dbarboza@ventanamicro.com > CC: zhiwei_liu@linux.alibaba.com > CC: imammedo@redhat.com > CC: anisinha@redhat.com > CC: philmd@linaro.org > CC: wangyanan55@huawei.com > CC: eblake@redhat.com > CC: armbru@redhat.com > CC: qemu-arm@nongnu.org > CC: qemu-riscv@nongnu.org > CC: f.ebner@proxmox.com > > Igor Mammedov (19): > tests: smbios: make it possible to write SMBIOS only test > tests: smbios: add test for -smbios type=11 option > tests: smbios: add test for legacy mode CLI options > smbios: cleanup smbios_get_tables() from legacy handling > smbios: get rid of smbios_smp_sockets global > smbios: get rid of smbios_legacy global > smbios: avoid mangling user provided tables > smbios: don't check type4 structures in legacy mode > smbios: build legacy mode code only for 'pc' machine > smbios: handle errors consistently > smbios: clear smbios_tables pointer after freeing > get rid of global smbios_ep_type > smbios: extend smbios-entry-point-type with 'auto' value > smbios: in case of entry point is 'auto' try to build v2 tables 1st > smbios: error out when building type 4 table is not possible > smbios: clear smbios_type4_count before building tables > tests: acpi/smbios: whitelist expected blobs > pc/q35: set SMBIOS entry point type to 'auto' by default > tests: acpi: update expected SSDT.dimmpxm blob > > hw/i386/fw_cfg.h | 3 +- > include/hw/firmware/smbios.h | 29 +- > hw/arm/virt.c | 6 +- > hw/i386/Kconfig | 1 + > hw/i386/fw_cfg.c | 14 +- > hw/i386/pc.c | 4 +- > hw/i386/pc_piix.c | 4 + > hw/i386/pc_q35.c | 3 + > hw/loongarch/virt.c | 7 +- > hw/riscv/virt.c | 6 +- > hw/smbios/Kconfig | 2 + > hw/smbios/meson.build | 4 + > hw/smbios/smbios.c | 481 +++++++++++---------------- > hw/smbios/smbios_legacy.c | 185 +++++++++++ > hw/smbios/smbios_legacy_stub.c | 16 + > qapi/machine.json | 5 +- > tests/data/acpi/q35/SSDT.dimmpxm | Bin 1815 -> 1815 bytes > tests/data/smbios/type11_blob | Bin 0 -> 11 bytes > tests/data/smbios/type11_blob.legacy | Bin 0 -> 10 bytes > tests/qtest/bios-tables-test.c | 81 ++++- > 20 files changed, 535 insertions(+), 316 deletions(-) > create mode 100644 hw/smbios/smbios_legacy.c > create mode 100644 hw/smbios/smbios_legacy_stub.c > create mode 100644 tests/data/smbios/type11_blob > create mode 100644 tests/data/smbios/type11_blob.legacy > > -- > 2.39.3
On Tue, 5 Mar 2024 05:08:05 -0500 "Michael S. Tsirkin" <mst@redhat.com> wrote: > On Tue, Feb 27, 2024 at 04:47:30PM +0100, Igor Mammedov wrote: > > Windows (10) bootloader when running on top of SeaBIOS, fails to find > > SMBIOSv3 entry point. Tracing it shows that it looks for v2 anchor markers > > only and not v3. Tricking it into believing that entry point is found > > lets Windows successfully locate and parse SMBIOSv3 tables. Whether it > > will be fixed on Windows side is not clear so here goes a workaround. > > > > Idea is to try build v2 tables if QEMU configuration permits, > > and fallback to v3 tables otherwise. That will mask Windows issue > > form majority of users. > > However if VM configuration can't be described (typically large VMs) > > by v2 tables, QEMU will use SMBIOSv3 and Windows will hit the issue > > again. In this case complain to Microsoft and/or use UEFI instead of > > SeaBIOS (requires reinstall). > > Igor so you want to repost a version with a couple of patches squashed? requested changes where in several patches (style and making series easier to review), I'll repost series with those changes today. > > Default compat setting of smbios-entry-point-type after series > > for pc/q35 machines: > > * 9.0-newer: 'auto' > > * 8.1-8.2: '64' > > * 8.0-older: '32' > > > > Fixes: https://gitlab.com/qemu-project/qemu/-/issues/2008 > > CC: peter.maydell@linaro.org > > CC: pbonzini@redhat.com > > CC: mst@redhat.com > > CC: gaosong@loongson.cn > > CC: alistair.francis@wdc.com > > CC: palmer@dabbelt.com > > CC: bin.meng@windriver.com > > CC: liwei1518@gmail.com > > CC: dbarboza@ventanamicro.com > > CC: zhiwei_liu@linux.alibaba.com > > CC: imammedo@redhat.com > > CC: anisinha@redhat.com > > CC: philmd@linaro.org > > CC: wangyanan55@huawei.com > > CC: eblake@redhat.com > > CC: armbru@redhat.com > > CC: qemu-arm@nongnu.org > > CC: qemu-riscv@nongnu.org > > CC: f.ebner@proxmox.com > > > > Igor Mammedov (19): > > tests: smbios: make it possible to write SMBIOS only test > > tests: smbios: add test for -smbios type=11 option > > tests: smbios: add test for legacy mode CLI options > > smbios: cleanup smbios_get_tables() from legacy handling > > smbios: get rid of smbios_smp_sockets global > > smbios: get rid of smbios_legacy global > > smbios: avoid mangling user provided tables > > smbios: don't check type4 structures in legacy mode > > smbios: build legacy mode code only for 'pc' machine > > smbios: handle errors consistently > > smbios: clear smbios_tables pointer after freeing > > get rid of global smbios_ep_type > > smbios: extend smbios-entry-point-type with 'auto' value > > smbios: in case of entry point is 'auto' try to build v2 tables 1st > > smbios: error out when building type 4 table is not possible > > smbios: clear smbios_type4_count before building tables > > tests: acpi/smbios: whitelist expected blobs > > pc/q35: set SMBIOS entry point type to 'auto' by default > > tests: acpi: update expected SSDT.dimmpxm blob > > > > hw/i386/fw_cfg.h | 3 +- > > include/hw/firmware/smbios.h | 29 +- > > hw/arm/virt.c | 6 +- > > hw/i386/Kconfig | 1 + > > hw/i386/fw_cfg.c | 14 +- > > hw/i386/pc.c | 4 +- > > hw/i386/pc_piix.c | 4 + > > hw/i386/pc_q35.c | 3 + > > hw/loongarch/virt.c | 7 +- > > hw/riscv/virt.c | 6 +- > > hw/smbios/Kconfig | 2 + > > hw/smbios/meson.build | 4 + > > hw/smbios/smbios.c | 481 +++++++++++---------------- > > hw/smbios/smbios_legacy.c | 185 +++++++++++ > > hw/smbios/smbios_legacy_stub.c | 16 + > > qapi/machine.json | 5 +- > > tests/data/acpi/q35/SSDT.dimmpxm | Bin 1815 -> 1815 bytes > > tests/data/smbios/type11_blob | Bin 0 -> 11 bytes > > tests/data/smbios/type11_blob.legacy | Bin 0 -> 10 bytes > > tests/qtest/bios-tables-test.c | 81 ++++- > > 20 files changed, 535 insertions(+), 316 deletions(-) > > create mode 100644 hw/smbios/smbios_legacy.c > > create mode 100644 hw/smbios/smbios_legacy_stub.c > > create mode 100644 tests/data/smbios/type11_blob > > create mode 100644 tests/data/smbios/type11_blob.legacy > > > > -- > > 2.39.3 >
Windows (10) bootloader when running on top of SeaBIOS, fails to find SMBIOSv3 entry point. Tracing it shows that it looks for v2 anchor markers only and not v3. Tricking it into believing that entry point is found lets Windows successfully locate and parse SMBIOSv3 tables. Whether it will be fixed on Windows side is not clear so here goes a workaround. Idea is to try build v2 tables if QEMU configuration permits, and fallback to v3 tables otherwise. That will mask Windows issue form majority of users. However if VM configuration can't be described (typically large VMs) by v2 tables, QEMU will use SMBIOSv3 and Windows will hit the issue again. In this case complain to Microsoft and/or use UEFI instead of SeaBIOS (requires reinstall). Default compat setting of smbios-entry-point-type after series for pc/q35 machines: * 9.0-newer: 'auto' * 8.1-8.2: '64' * 8.0-older: '32' Fixes: https://gitlab.com/qemu-project/qemu/-/issues/2008 CC: peter.maydell@linaro.org CC: pbonzini@redhat.com CC: mst@redhat.com CC: gaosong@loongson.cn CC: alistair.francis@wdc.com CC: palmer@dabbelt.com CC: bin.meng@windriver.com CC: liwei1518@gmail.com CC: dbarboza@ventanamicro.com CC: zhiwei_liu@linux.alibaba.com CC: imammedo@redhat.com CC: anisinha@redhat.com CC: philmd@linaro.org CC: wangyanan55@huawei.com CC: eblake@redhat.com CC: armbru@redhat.com CC: qemu-arm@nongnu.org CC: qemu-riscv@nongnu.org CC: f.ebner@proxmox.com Igor Mammedov (19): tests: smbios: make it possible to write SMBIOS only test tests: smbios: add test for -smbios type=11 option tests: smbios: add test for legacy mode CLI options smbios: cleanup smbios_get_tables() from legacy handling smbios: get rid of smbios_smp_sockets global smbios: get rid of smbios_legacy global smbios: avoid mangling user provided tables smbios: don't check type4 structures in legacy mode smbios: build legacy mode code only for 'pc' machine smbios: handle errors consistently smbios: clear smbios_tables pointer after freeing get rid of global smbios_ep_type smbios: extend smbios-entry-point-type with 'auto' value smbios: in case of entry point is 'auto' try to build v2 tables 1st smbios: error out when building type 4 table is not possible smbios: clear smbios_type4_count before building tables tests: acpi/smbios: whitelist expected blobs pc/q35: set SMBIOS entry point type to 'auto' by default tests: acpi: update expected SSDT.dimmpxm blob hw/i386/fw_cfg.h | 3 +- include/hw/firmware/smbios.h | 29 +- hw/arm/virt.c | 6 +- hw/i386/Kconfig | 1 + hw/i386/fw_cfg.c | 14 +- hw/i386/pc.c | 4 +- hw/i386/pc_piix.c | 4 + hw/i386/pc_q35.c | 3 + hw/loongarch/virt.c | 7 +- hw/riscv/virt.c | 6 +- hw/smbios/Kconfig | 2 + hw/smbios/meson.build | 4 + hw/smbios/smbios.c | 481 +++++++++++---------------- hw/smbios/smbios_legacy.c | 185 +++++++++++ hw/smbios/smbios_legacy_stub.c | 16 + qapi/machine.json | 5 +- tests/data/acpi/q35/SSDT.dimmpxm | Bin 1815 -> 1815 bytes tests/data/smbios/type11_blob | Bin 0 -> 11 bytes tests/data/smbios/type11_blob.legacy | Bin 0 -> 10 bytes tests/qtest/bios-tables-test.c | 81 ++++- 20 files changed, 535 insertions(+), 316 deletions(-) create mode 100644 hw/smbios/smbios_legacy.c create mode 100644 hw/smbios/smbios_legacy_stub.c create mode 100644 tests/data/smbios/type11_blob create mode 100644 tests/data/smbios/type11_blob.legacy