On Fri, Dec 29, 2023 at 04:35:14PM +0100, Igor Mammedov wrote: > On Thu, 30 Nov 2023 12:22:37 +0100 > Igor Mammedov <imamm...@redhat.com> wrote: > > > On Wed, 29 Nov 2023 11:01:07 +0100 > > Igor Mammedov <imamm...@redhat.com> wrote: > > > > > On Tue, 28 Nov 2023 11:00:29 -0500 > > > "Michael S. Tsirkin" <m...@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
