| Message ID | 59c230dab17176f798fb938ba4318543d9cf31d8.1687782442.git.mst@redhat.com |
|---|---|
| State | New |
| Headers | show |
| Series | [PULL,01/53] bswap: Add the ability to store to an unaligned 24 bit field | expand |
Am 26.06.23 um 14:29 schrieb Michael S. Tsirkin: > From: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com> > > Currently, pc-q35 and pc-i44fx machine models are default to use SMBIOS 2.8 > (32-bit entry point). Since SMBIOS 3.0 (64-bit entry point) is now fully > supported since QEMU 7.0, default to use SMBIOS 3.0 for newer machine > models. This is necessary to avoid the following message when launching > a VM with large number of vcpus. > > "SMBIOS 2.1 table length 66822 exceeds 65535" > > Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com> > Message-Id: <20230607205717.737749-2-suravee.suthikulpanit@amd.com> > Reviewed-by: Michael S. Tsirkin <mst@redhat.com> > Signed-off-by: Michael S. Tsirkin <mst@redhat.com> > Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> > Reviewed-by: Igor Mammedov <imammedo@redhat.com> Hi, 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? Best Regards, Fiona [0]: https://forum.proxmox.com/threads/136942/ [1]: https://forum.proxmox.com/threads/136227/post-610277
On Tue, Nov 28, 2023 at 02:57:17PM +0100, Fiona Ebner wrote: > Am 26.06.23 um 14:29 schrieb Michael S. Tsirkin: > > From: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com> > > > > Currently, pc-q35 and pc-i44fx machine models are default to use SMBIOS 2.8 > > (32-bit entry point). Since SMBIOS 3.0 (64-bit entry point) is now fully > > supported since QEMU 7.0, default to use SMBIOS 3.0 for newer machine > > models. This is necessary to avoid the following message when launching > > a VM with large number of vcpus. > > > > "SMBIOS 2.1 table length 66822 exceeds 65535" > > > > Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com> > > Message-Id: <20230607205717.737749-2-suravee.suthikulpanit@amd.com> > > Reviewed-by: Michael S. Tsirkin <mst@redhat.com> > > Signed-off-by: Michael S. Tsirkin <mst@redhat.com> > > Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> > > Reviewed-by: Igor Mammedov <imammedo@redhat.com> > > Hi, > > 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 With regards, Daniel
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
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?
On Tue, Nov 28, 2023 at 11:00:29AM -0500, Michael S. Tsirkin 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. IIRC, it wasn't merely number of vCPUs that was a problem - a number of other aspects can also influence the SMBIOS table size. With regards, Daniel
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.
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.
Hi, > 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. seabios version must be 1.16.x. The version bundled with qemu should be new enough for smbios 3.0 for more than a year now. take care, Gerd
Am 30.11.23 um 12:47 schrieb Gerd Hoffmann: > Hi, > >> 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. > > seabios version must be 1.16.x. > > The version bundled with qemu should be new enough for smbios 3.0 for > more than a year now. > I tested with QEMU 8.1 and the bundled SeaBIOS version there is 1.16.2. With Linux VMs, I can see the UUID from the SMBIOS table when using smbios-entry-point-type=64, but not with Windows VMs. Sorry, I realized that I didn't even mention that it works with Linux until now. I'll add that info to the GitLab issue too. Best Regards, Fiona
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.
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?
On Fri, 29 Dec 2023 10:45:08 -0500 "Michael S. Tsirkin" <mst@redhat.com> wrote: > 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? Let me finish it then and see how it turns out. With UEFI, Windows gets tables from firmware (i.e. it doesn't search, otherwise they would've gotten bug reports long time ago).
diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h index c661e9cc80..6eec0fc51d 100644 --- a/include/hw/i386/pc.h +++ b/include/hw/i386/pc.h @@ -110,6 +110,7 @@ struct PCMachineClass { bool smbios_defaults; bool smbios_legacy_mode; bool smbios_uuid_encoded; + SmbiosEntryPointType default_smbios_ep_type; /* RAM / address space compat: */ bool gigabyte_align; diff --git a/tests/qtest/bios-tables-test-allowed-diff.h b/tests/qtest/bios-tables-test-allowed-diff.h index dfb8523c8b..81148a604f 100644 --- a/tests/qtest/bios-tables-test-allowed-diff.h +++ b/tests/qtest/bios-tables-test-allowed-diff.h @@ -1 +1,2 @@ /* List of comma-separated changed AML files to ignore */ +"tests/data/acpi/q35/SSDT.dimmpxm", diff --git a/hw/i386/pc.c b/hw/i386/pc.c index fc52772fdd..8d37567e08 100644 --- a/hw/i386/pc.c +++ b/hw/i386/pc.c @@ -1856,6 +1856,7 @@ static void pc_machine_set_max_fw_size(Object *obj, Visitor *v, static void pc_machine_initfn(Object *obj) { PCMachineState *pcms = PC_MACHINE(obj); + PCMachineClass *pcmc = PC_MACHINE_GET_CLASS(pcms); #ifdef CONFIG_VMPORT pcms->vmport = ON_OFF_AUTO_AUTO; @@ -1863,7 +1864,7 @@ static void pc_machine_initfn(Object *obj) pcms->vmport = ON_OFF_AUTO_OFF; #endif /* CONFIG_VMPORT */ pcms->max_ram_below_4g = 0; /* use default */ - pcms->smbios_entry_point_type = SMBIOS_ENTRY_POINT_TYPE_32; + pcms->smbios_entry_point_type = pcmc->default_smbios_ep_type; /* acpi build is enabled by default if machine supports it */ pcms->acpi_build_enabled = PC_MACHINE_GET_CLASS(pcms)->has_acpi_build; @@ -1975,6 +1976,7 @@ static void pc_machine_class_init(ObjectClass *oc, void *data) mc->nvdimm_supported = true; mc->smp_props.dies_supported = true; mc->default_ram_id = "pc.ram"; + pcmc->default_smbios_ep_type = SMBIOS_ENTRY_POINT_TYPE_64; object_class_property_add(oc, PC_MACHINE_MAX_RAM_BELOW_4G, "size", pc_machine_get_max_ram_below_4g, pc_machine_set_max_ram_below_4g, diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c index 44146e6ff5..f9947fbc10 100644 --- a/hw/i386/pc_piix.c +++ b/hw/i386/pc_piix.c @@ -506,11 +506,16 @@ DEFINE_I440FX_MACHINE(v8_1, "pc-i440fx-8.1", NULL, static void pc_i440fx_8_0_machine_options(MachineClass *m) { + PCMachineClass *pcmc = PC_MACHINE_CLASS(m); + pc_i440fx_8_1_machine_options(m); m->alias = NULL; m->is_default = false; compat_props_add(m->compat_props, hw_compat_8_0, hw_compat_8_0_len); compat_props_add(m->compat_props, pc_compat_8_0, pc_compat_8_0_len); + + /* For pc-i44fx-8.0 and older, use SMBIOS 2.8 by default */ + pcmc->default_smbios_ep_type = SMBIOS_ENTRY_POINT_TYPE_32; } DEFINE_I440FX_MACHINE(v8_0, "pc-i440fx-8.0", NULL, diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c index a9a59ed42b..cf68b80974 100644 --- a/hw/i386/pc_q35.c +++ b/hw/i386/pc_q35.c @@ -387,10 +387,15 @@ DEFINE_Q35_MACHINE(v8_1, "pc-q35-8.1", NULL, static void pc_q35_8_0_machine_options(MachineClass *m) { + PCMachineClass *pcmc = PC_MACHINE_CLASS(m); + pc_q35_8_1_machine_options(m); m->alias = NULL; compat_props_add(m->compat_props, hw_compat_8_0, hw_compat_8_0_len); compat_props_add(m->compat_props, pc_compat_8_0, pc_compat_8_0_len); + + /* For pc-q35-8.0 and older, use SMBIOS 2.8 by default */ + pcmc->default_smbios_ep_type = SMBIOS_ENTRY_POINT_TYPE_32; } DEFINE_Q35_MACHINE(v8_0, "pc-q35-8.0", NULL,