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.web11.51489.1673518163566073545 for ; Thu, 12 Jan 2023 02:09:24 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=q4MQHceZ; 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 A1A38B81C0B for ; Thu, 12 Jan 2023 10:09:21 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 491DCC433D2 for ; Thu, 12 Jan 2023 10:09:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1673518160; bh=CD8n+jIRsfjTmi/t0evFH5GKPJTjuxCm0WyaMy4nNXI=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=q4MQHceZHOZkaTsHGkrf8j5WEZgau785Icw/+TO/xMM/rRaIIP2I1ulIWHIt/tI3s TPiA3iaj/RPF/noZkkT/JFpTPvA/I+lXPmNQW77appToFwxH366JjztOHsLkC9Zh2s VByHpbGHlMGpYp3r6OnY+LWzzr7dTIIZkB+huzOcqDFuCfqWzN3ngTeu4tSQntqXNw Olukg8jzsuTiFAeSs7Uqkpcr3lWkMTITCpyc+AmtgV+VPI9SmLlklGY9dTrmMDInBo ehUeh3Puc+tp4TIYarBMZpZbUqibDfGa+/JF1yFEHfO55AATAb6ho4tyoYl3yDlLH5 bormD1F//wMBQ== Received: by mail-lf1-f44.google.com with SMTP id bt23so27654429lfb.5 for ; Thu, 12 Jan 2023 02:09:20 -0800 (PST) X-Gm-Message-State: AFqh2kqmLeIpNEslxJ/aTh9JW3LxgLcswUNzreccnNM6LXicOi1/COIG M3BVhvlSEWrYGizrTkaoB6N0a5IZncNb3nvw1Fs= X-Google-Smtp-Source: AMrXdXtUqreSTAXwWH01jwo0mAY+Mi/dnAJliyopLWtoVg4oVC3xysQd52KzuPTF7u8usfdnAK5FthNnSv9lLTqvdhc= X-Received: by 2002:ac2:5d4e:0:b0:4b5:964d:49a4 with SMTP id w14-20020ac25d4e000000b004b5964d49a4mr6663553lfd.637.1673518158318; Thu, 12 Jan 2023 02:09:18 -0800 (PST) MIME-Version: 1.0 References: <20230112082845.128463-1-lersek@redhat.com> <01020185a568604c-e16d8581-963a-4ff3-8566-bf0640ad327d-000000@eu-west-1.amazonses.com> In-Reply-To: <01020185a568604c-e16d8581-963a-4ff3-8566-bf0640ad327d-000000@eu-west-1.amazonses.com> From: "Ard Biesheuvel" Date: Thu, 12 Jan 2023 11:09:06 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [edk2-devel] [PATCH v2] OvmfPkg/PlatformInitLib: catch QEMU's CPU hotplug reg block regression To: devel@edk2.groups.io, mcb30@ipxe.org Cc: lersek@redhat.com, Ard Biesheuvel , Brijesh Singh , Erdem Aktas , Gerd Hoffmann , James Bottomley , Jiewen Yao , Jordan Justen , Min Xu , Oliver Steffen , Sebastien Boeuf , Tom Lendacky Content-Type: text/plain; charset="UTF-8" On Thu, 12 Jan 2023 at 10:56, Michael Brown wrote: > > On 12/01/2023 08:28, Laszlo Ersek wrote: > > In QEMU v5.1.0, the CPU hotplug register block misbehaves: the negotiation > > protocol is (effectively) broken such that it suggests that switching from > > the legacy interface to the modern interface works, but in reality the > > switch never happens. The symptom has been witnessed when using TCG > > acceleration; KVM seems to mask the issue. The issue persists with the > > following (latest) stable QEMU releases: v5.2.0, v6.2.0, v7.2.0. Currently > > there is no stable release that addresses the problem. > > > > The QEMU bug confuses the Present and Possible counting in function > > PlatformMaxCpuCountInitialization(), in > > "OvmfPkg/Library/PlatformInitLib/Platform.c". OVMF ends up with Present=0 > > Possible=1. This in turn further confuses MpInitLib in UefiCpuPkg (hence > > firmware-time multiprocessing will be broken). Worse, CPU hot(un)plug with > > SMI will be summarily broken in OvmfPkg/CpuHotplugSmm, which (considering > > the privilege level of SMM) is not that great. > > > > Detect the issue in PlatformMaxCpuCountInitialization(), and print an > > error message and *hang* if the issue is present. > > Would this mean that OVMF would refuse to start with all current distro > versions of qemu (when not using KVM), or am I misunderstanding? > I had the same question, actually. This would be less than ideal, especially given the fact that I didn't even notice the breakage, and Linux happily booted on all cores. If this is a security issue that affects SMM, could we make this behavior dependent on REQUIRE_SMM perhaps?