Re: [PULL 31/53] hw/i386/pc: Default to use SMBIOS 3.0 for newer machine models

["Michael S. Tsirkin" <mst@redhat.com>]

On Fri, Dec 29, 2023 at 04:35:14PM +0100, Igor Mammedov wrote:
> On Thu, 30 Nov 2023 12:22:37 +0100
> Igor Mammedov <imammedo@redhat.com> wrote:
> 
> > On Wed, 29 Nov 2023 11:01:07 +0100
> > Igor Mammedov <imammedo@redhat.com> wrote:
> > 
> > > On Tue, 28 Nov 2023 11:00:29 -0500
> > > "Michael S. Tsirkin" <mst@redhat.com> wrote:
> > >   
> > > > On Tue, Nov 28, 2023 at 03:53:21PM +0100, Fiona Ebner wrote:    
> > > > > Am 28.11.23 um 15:13 schrieb Daniel P. Berrangé:      
> > > > > > On Tue, Nov 28, 2023 at 02:57:17PM +0100, Fiona Ebner wrote:      
> > > > > >> we received some reports about the new default causing issues for
> > > > > >> certain guest OSes [0][1]. Namely, for Juniper vSRX, where boot fails
> > > > > >> and Microsoft Windows, where querying an UUID set via QEMU cmdline
> > > > > >> -smbios 'type=1,uuid=a4656bd0-a07d-48e0-9dfd-bdc84667a8d0'
> > > > > >> in Powershell with
> > > > > >> get-wmiobject win32_computersystemproduct | Select-Object
> > > > > >> -expandProperty UUID
> > > > > >> doesn't return any value anymore and can trip up some guest
> > > > > >> applications. The original report is about Windows 10 and I reproduced
> > > > > >> this with Windows Server 2019 and the German (but I hope it doesn't
> > > > > >> matter this time) version of Windows Server 2022.
> > > > > >>
> > > > > >> Using machine type 8.0 or the machine option smbios-entry-point-type=32
> > > > > >> are workarounds.
> > > > > >>
> > > > > >> Since Windows is widely used, that seems a bit unfortunate. Just wanted
> > > > > >> to ask if you are aware of the issue and if there is something else that
> > > > > >> can be done other than specifying the more specific machine commandline
> > > > > >> for those OSes?      
> > > > > > 
> > > > > > I don't recall seeing this issue mentioned before. Could you file a
> > > > > > bug at https://gitlab.com/qemu-project/qemu
> > > > > >       
> > > > > 
> > > > > I made one for the Windows issue:
> > > > > https://gitlab.com/qemu-project/qemu/-/issues/2008
> > > > > 
> > > > > It's not clear to me if this is a bug in QEMU or just a bug/limitation
> > > > > of the guest OS when 64 bit entry is used by SMBIOS.
> > > > > 
> > > > > I didn't create one for vSRX, because I'm not using it myself and since
> > > > > it's based on FreeBSD and FreeBSD 13.1 can boot just fine with both 32
> > > > > and 64 bit entry, it might be an issue on their side.
> > > > > 
> > > > > Best Regards,
> > > > > Fiona      
> > > > 
> > > > I would be inclined to limit this to when we have too many VCPUs then.
> > > > Igor WDYT?    
> > > 
> > > Let me try to reproduce and see if Windows debug logs would provide some clue.  
> > 
> > Nothing notable in debug output on Windows side, but it looks like Windows
> > doesn't see SMBIOS tables at all.
> > 
> > However it affects VMs with Seabios only, UEFI based VMs work just fine.
> > My guess would be it's not QEMU issue, but Seabios one.
> > I'm still looking at it,
> > but CCing Gerd, who might have an idea what's going wrong from firmware pov. 
> > 
> 
> So running Seabios VM with Win10 as a guest under debugger
> (set access breakpoint on SMBIOS anchor string), one can see
> that Windows doesn't look for _SM3_ signature during lookup
> at all. While after some convincing and making make lookup
> code return SMBIOS 3.x entrypoint, the rest of Windows handles
> SMBIOS 3.x just fine and shows UUID /using Fiona's reproducer/.
> 
> So it's bug in Windows.
> 
> As for qemu, I'd guess we'd just have to live with it until MS
> fixes it and even after that it won't help with unsupported versions
> as they are not likely to get fix.
> 
> To that effect, we have 3 options:
>    1. make mgmt force 32bit entry point if they are starting Windows VM
>    2. unconditionally switch pc|q35 9.0+ machine types to 32bit entry point
>       and error out if configuration doesn't fit into SMBIOS 2.0 tables
>       (easiest from QEMU pov)
>    3. introduce 'auto' value for smbios entry point option, and then
>       try to stick with 32bit entry point while it is usable
>       (cpu count < 256 and tables still fit in guest's FSEG RAM).
>       When that fails switch dynamically to 64bit entry point.
> 
> Any opinions on preferable route?
> 
> I'm looking into my least favorite option 3 atm, and it's pretty messy
> with current SMBIOS code and needs quite a bit of cleanup.

I like 3 as the least disruptive ... but UEFI works do you know why?


-- 
MST