qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v3 00/20] Workaround Windows failing to find 64bit SMBIOS ent


From: Igor Mammedov
Subject: Re: [PATCH v3 00/20] Workaround Windows failing to find 64bit SMBIOS entry point with SeaBIOS
Date: Wed, 13 Mar 2024 09:49:39 +0100

On Tue, 12 Mar 2024 13:31:39 -0400
"Michael S. Tsirkin" <mst@redhat.com> wrote:

> On Tue, Mar 12, 2024 at 05:10:30PM +0100, Igor Mammedov wrote:
> > Changelog:
> >  v3:
> >    * whitespace missed by checkpatch
> >    * fix idndent in QAPI
> >    * reorder 17/20 before 1st 'auto' can be used
> >    * pick up acks
> >  v2:
> >    * QAPI style fixes (Markus Armbruster <armbru@redhat.com>)
> >    * squash 11/19 into 10/19 (Ani Sinha <anisinha@redhat.com>)
> >    * split '[PATCH 09/19] smbios: build legacy mode code only for 'pc' 
> > machine'
> >      in 3 smaller patches, to make it more readable
> >        smbios: add smbios_add_usr_blob_size() helper                        
> >           
> >        smbios: rename/expose structures/bitmaps used by both legacy and 
> > modern code                                                                 
> >  
> >        smbios: build legacy mode code only for 'pc' machine
> >    * pick up acks  
> 
> thanks!
> of course this conflicts with
> SMBIOS type 9
> and I am trying to figure out how to resolve this again.

I'll rebase once your pull req is merged. 

> Do you ack SMBIOS type 9 btw?
nope, and it seems it's too late do so now.

> 
> > 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: imammedo@redhat.com                                                     
> >      
> > CC: mst@redhat.com
> > 
> > Igor Mammedov (20):
> >   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: add smbios_add_usr_blob_size() helper
> >   smbios: rename/expose structures/bitmaps used by both legacy and
> >     modern code
> >   smbios: build legacy mode code only for 'pc' machine
> >   smbios: handle errors consistently
> >   smbios: get rid of global smbios_ep_type
> >   smbios: clear smbios_type4_count before building tables
> >   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
> >   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         |  28 +-
> >  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       |  15 +
> >  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, 533 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  
> 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]