On Fri, 20 Jan 2023 at 10:25, Laszlo Ersek <ler...@redhat.com> wrote: > > On 1/19/23 14:43, Ard Biesheuvel wrote: > > QEMU for x86 has a nasty CPU hotplug bug of which the ramifications are > > difficult to oversee, even though KVM acceleration seems to be > > unaffected. This has been addressed in QEMU mainline, and will percolate > > through the ecosystem at its usual pace. In the mean time, due to the > > potential impact on production workloads, we will be updating OVMF to > > abort the boot when it detects a QEMU build that is affected. > > > > Tiancore's platform CI uses QEMU in TCG mode, and is therefore impacted > > by this mitigation, unless its QEMU builds are updated. This has been > > done for Ubuntu-GCC5, but Windows-VS2019 still uses a QEMU build that is > > affected. > > > > Aborting the boot upon detecting the QEMU issue will render all boot > > tests carried out on Windows-VS2019 broken unless we implement the > > 'escape hatch' that enables proceed-at-your-own-risk mode, and permits > > the boot to proceed even if the QEMU issue is detected. > > > > So let's enable this for Windows-VS2019, and remove it again once it is > > no longer needed. > > > > Cc: Laszlo Ersek <ler...@redhat.com> > > Cc: Gerd Hoffmann <kra...@redhat.com> > > Cc: Jiewen Yao <jiewen....@intel.com> > > Cc: Michael Brown <mc...@ipxe.org> > > Cc: Oliver Steffen <ostef...@redhat.com> > > Cc: Michael Kubacki <michael.kuba...@microsoft.com> > > > > Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=4250 > > Signed-off-by: Ard Biesheuvel <a...@kernel.org> > > --- > > OvmfPkg/PlatformCI/.azurepipelines/Windows-VS2019.yml | 2 +- > > OvmfPkg/PlatformCI/PlatformBuildLib.py | 12 ++++++++++++ > > 2 files changed, 13 insertions(+), 1 deletion(-) > > > > diff --git a/OvmfPkg/PlatformCI/.azurepipelines/Windows-VS2019.yml > > b/OvmfPkg/PlatformCI/.azurepipelines/Windows-VS2019.yml > > index 7e63f419b26b..b3b91aa84ea0 100644 > > --- a/OvmfPkg/PlatformCI/.azurepipelines/Windows-VS2019.yml > > +++ b/OvmfPkg/PlatformCI/.azurepipelines/Windows-VS2019.yml > > @@ -24,7 +24,7 @@ jobs: > > package: 'OvmfPkg' > > vm_image: 'windows-2019' > > should_run: true > > - run_flags: "MAKE_STARTUP_NSH=TRUE QEMU_HEADLESS=TRUE" > > + run_flags: "MAKE_STARTUP_NSH=TRUE QEMU_HEADLESS=TRUE > > QEMU_CPUHP_QUIRK=TRUE" > > > > #Use matrix to speed up the build process > > strategy: > > diff --git a/OvmfPkg/PlatformCI/PlatformBuildLib.py > > b/OvmfPkg/PlatformCI/PlatformBuildLib.py > > index bfef9849c749..58dc1189a2cc 100644 > > --- a/OvmfPkg/PlatformCI/PlatformBuildLib.py > > +++ b/OvmfPkg/PlatformCI/PlatformBuildLib.py > > @@ -170,6 +170,7 @@ class PlatformBuilder( UefiBuilder, > > BuildSettingsManager): > > self.env.SetValue("PRODUCT_NAME", "OVMF", "Platform Hardcoded") > > self.env.SetValue("MAKE_STARTUP_NSH", "FALSE", "Default to false") > > self.env.SetValue("QEMU_HEADLESS", "FALSE", "Default to false") > > + self.env.SetValue("QEMU_CPUHP_QUIRK", "FALSE", "Default to false") > > return 0 > > > > def PlatformPreBuild(self): > > @@ -211,6 +212,17 @@ class PlatformBuilder( UefiBuilder, > > BuildSettingsManager): > > args += " -pflash " + os.path.join(OutputPath_FV, "OVMF.fd") > > # path to firmware > > > > > > + ### > > + ### NOTE This is a temporary workaround to allow platform CI to > > cope with > > + ### a QEMU bug in the CPU hotplug code. Once the CI > > environment has > > + ### been updated to carry a fixed version of QEMU, this can be > > + ### removed again > > + ### > > + ### Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=4250 > > + ### > > + if (self.env.GetValue("QEMU_CPUHP_QUIRK").upper() == "TRUE"): > > + args += " -fw_cfg > > name=opt/org.tianocore/X-Cpuhp-Bugcheck-Override,string=yes" > > + > > if (self.env.GetValue("MAKE_STARTUP_NSH").upper() == "TRUE"): > > f = open(os.path.join(VirtualDrive, "startup.nsh"), "w") > > f.write("BOOT SUCCESS !!! \n") > > Reviewed-by: Laszlo Ersek <ler...@redhat.com> > > Technically speaking, can I merge this *prepended* to my v3 patch set > ([PATCH v3 0/2] OvmfPkg/PlatformInitLib: catch QEMU's CPU hotplug reg > block regression), in the *same* PR? > > Because then I'll do that, saving us a bit of duplicated work. >
Yes, please go ahead and merge this if it is all ready to go. I won't get around to it to later this afternoon. > I'll then also file the BZ for reverting this (once I know the commit > hash), for when a new QEMU is out for Windows -- whom should I assign > that BZ? Oliver or Ard? > You can assign it to me. And please put Michael Kubacki on cc as well. -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#98917): https://edk2.groups.io/g/devel/message/98917 Mute This Topic: https://groups.io/mt/96377034/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
