From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by mx.groups.io with SMTP id smtpd.web10.70720.1674208465586816209 for ; Fri, 20 Jan 2023 01:54:26 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=kUlbLsE0; spf=pass (domain: kernel.org, ip: 145.40.68.75, mailfrom: ardb@kernel.org) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 5F256B8184F for ; Fri, 20 Jan 2023 09:54:23 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 169DBC433EF for ; Fri, 20 Jan 2023 09:54:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1674208462; bh=7HGMY82p/+Ipe6afR86roRe+piiPoa9PsNFPjZzhzus=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=kUlbLsE0VKt3Vrr1odihEviRDqvIIOCDD4HpVwPHzZi7y1GV8RMxOKgQdWXRCyn1v f8Ou8enrG8UXgfjzcqORDco3Pb+Nd38MeBX1Oh+NYP7hIrIztBEHGFL5te43g+BY3m yaNgNzB3yJYoRJdmjK/keQVb2/v/lbChD3J/hC4mTryo1aWn/Ol9hlZUbraCKPKYre Z3iY/Iat20gpPX3oKH1OoxIWuAl29f+7Vau2ERgMl8zBCDDsOaK7+lK3xViY4W76yO oUnZxOdrTw8dzYpxK9MK1bdLUok3tY/rVpF92bw56qMEt6IKV8G4DRQ8zWdcdvvr/j Mnf6LG4cdN8EQ== Received: by mail-lf1-f45.google.com with SMTP id d30so7271778lfv.8 for ; Fri, 20 Jan 2023 01:54:21 -0800 (PST) X-Gm-Message-State: AFqh2kpDwtgS4aWe1B4vS8PKrqoEmPQ650NHkwuGQ/pbdv4qQxSpSK84 fEywBNnqXlp/u5IClbk7npmMPKk+/TjjjigUSGg= X-Google-Smtp-Source: AMrXdXsmCOz8sIDwlHZMyu+p/zLbtUTNcvpjsSbZz+cXtzdxzr1viJBgg3tsCkdyyD6zhLp+53Dcofk8ieOpyWVLZXg= X-Received: by 2002:a19:c501:0:b0:4b8:9001:a694 with SMTP id w1-20020a19c501000000b004b89001a694mr738088lfe.426.1674208460015; Fri, 20 Jan 2023 01:54:20 -0800 (PST) MIME-Version: 1.0 References: <20230119134302.1524569-1-ardb@kernel.org> In-Reply-To: From: "Ard Biesheuvel" Date: Fri, 20 Jan 2023 10:54:07 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [edk2-devel] [RFC PATCH] OvmfPkg/PlatformCI VS2019: Enable temporary workaround for cpuhp bugfix To: devel@edk2.groups.io, lersek@redhat.com Cc: Oliver Steffen , Gerd Hoffmann , Jiewen Yao , Michael Brown , Michael Kubacki Content-Type: text/plain; charset="UTF-8" On Fri, 20 Jan 2023 at 10:25, Laszlo Ersek 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 > > Cc: Gerd Hoffmann > > Cc: Jiewen Yao > > Cc: Michael Brown > > Cc: Oliver Steffen > > Cc: Michael Kubacki > > > > Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=4250 > > Signed-off-by: Ard Biesheuvel > > --- > > 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 > > 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.