From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by mx.groups.io with SMTP id smtpd.web11.82788.1673604671730095402 for ; Fri, 13 Jan 2023 02:11:11 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=Y28avYf9; spf=pass (domain: redhat.com, ip: 170.10.129.124, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1673604670; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Fb+xl5g6Sf1AaQ7kIf3yeUw6OS0biIxrhkGSEb/0kHM=; b=Y28avYf9V/jjOeqHcqE1MtgCgDJdoi0dszSUME7iZyz5VA7qvHJHuUecF0OyZuS5CrtY+m yMwMNiDbhvESHk/nDMm2vJYlJKo4GoODDbLgt0a35PJXqVgligyOwZYdz/d+zw+E1yo+WI Yx4cRJI9PlaQdcb+f1jXmoBqPRtGv6g= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-359-MerZ9BZDMx2UWjC0FGEwWw-1; Fri, 13 Jan 2023 05:11:04 -0500 X-MC-Unique: MerZ9BZDMx2UWjC0FGEwWw-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.rdu2.redhat.com [10.11.54.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id CE01A1C0515F; Fri, 13 Jan 2023 10:11:03 +0000 (UTC) Received: from [10.39.195.47] (unknown [10.39.195.47]) by smtp.corp.redhat.com (Postfix) with ESMTPS id A75831400AFC; Fri, 13 Jan 2023 10:10:55 +0000 (UTC) Message-ID: Date: Fri, 13 Jan 2023 11:10:54 +0100 MIME-Version: 1.0 Subject: Re: [edk2-devel] [PATCH v2] OvmfPkg/PlatformInitLib: catch QEMU's CPU hotplug reg block regression To: Gerd Hoffmann , devel@edk2.groups.io Cc: Michael Brown , Ard Biesheuvel , Brijesh Singh , Erdem Aktas , James Bottomley , Jiewen Yao , Jordan Justen , Min Xu , Oliver Steffen , Sebastien Boeuf , Tom Lendacky References: <20230112082845.128463-1-lersek@redhat.com> <01020185a568604c-e16d8581-963a-4ff3-8566-bf0640ad327d-000000@eu-west-1.amazonses.com> <407c5cee-7a6c-cbc8-35cc-8f2c2724914c@redhat.com> <01020185a6bda78a-05d82180-4d1a-4af4-9a9b-ac78088d11ed-000000@eu-west-1.amazonses.com> <49e4e8bb-3bbd-0ca8-ee59-e75560deffa7@redhat.com> <20230113060354.siony3rjwpgzd5tk@sirius.home.kraxel.org> <20230113093205.oh7euprqlmp26wpu@sirius.home.kraxel.org> From: "Laszlo Ersek" In-Reply-To: <20230113093205.oh7euprqlmp26wpu@sirius.home.kraxel.org> X-Scanned-By: MIMEDefang 3.1 on 10.11.54.7 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 1/13/23 10:32, Gerd Hoffmann wrote: > On Fri, Jan 13, 2023 at 07:03:54AM +0100, Gerd Hoffmann wrote: >> Hi, >> >>> - QEMU can be configured with other compat properties on the command >>> line so that "CPU hotplug with SMI" and "CPU hot-unplug with SMI" *not* >>> be offered to the firmware. Then QEMU will reject hotplug attempts, and >>> the SMM hotplug code in edk2 will not be triggered by the (virtual) >>> hardware. >> >> Can we have edk2 print instructions for that in the error message? > > This seems to be: > > qemu -M q35 \ > -global ICH9-LPC.x-smi-cpu-hotplug=off \ > -global ICH9-LPC.x-smi-cpu-hotunplug=off Yes, those are the flags. > But it appears to not work. They should work, but they take effect in QEMU, and not in the firmware. These knobs control what CPU hot(un)plug+SMI features QEMU exposes to the guest fw, via fw_cfg, then the guest confirms those that it knows, and even locks the feature set down (IIRC). The same is replayed with an S3 bootscript snippet during S3 resume. Then, when you try to use a QMP command with QEMU for hotplugging or hot-unplugging a CPU (equiv. virsh commands that translate to such QMP commands), QEMU will allow or reject those commands based on the firmware's prior confirmation. That is, the knobs don't influence the firmware's behavior, the firmware just confirms to QEMU whether it can handle what. This makes it possible to run {old, new} firmware x { old, new } QEMU. In particular the firmware makes no further decisions based on whether QEMU advertized some of these features. Laszlo