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.201605.1673973849892856702 for ; Tue, 17 Jan 2023 08:44:10 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=prdlK3GA; 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 05774B81928 for ; Tue, 17 Jan 2023 16:44:08 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 274E1C43396 for ; Tue, 17 Jan 2023 16:44:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1673973846; bh=XY3rmG0FwO67xFRRtq4PMPbMcr4Ol6GrEduvd0ffAAk=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=prdlK3GAII3gOc0PJvZYKrq2ir6mG+l1/GwE9JSpLF4B+Wuopk6zgUZSiiaeqQR2I 0RsEMJKZ2+XbnlEdTCfXh4b23oOus91hdFgy1nWNZuyP8nFFWoD7Y64eSFQkbCF/Ty Bs27NjPIeugNIvnNs7evNliYHZszBlhAjGJpqnd0a8k9TPTxSgwZhn4noE3xofKGXs RnBBnXUjVFqDc7vYA2IGiCN7ehxsPnjkLbuSf8eD51pGz0oteAAXRoWphGZkzQEn6+ hv24sC16HVtRZNERoW3nQly8T1BAForUClFWWi9UJzrp5K8tZr7aghb70aYU/wJ4Dl Mk1UR4nWNlkUQ== Received: by mail-lj1-f179.google.com with SMTP id y18so30173984ljk.11 for ; Tue, 17 Jan 2023 08:44:06 -0800 (PST) X-Gm-Message-State: AFqh2kq5k0dBC5FH7lq5177tcaq62NZZ+slNdMKC9srnYMnixvNI8uri g2iYcBBeHpsGDKhZDeTF6SPE3qaCGg7/nddLD2Q= X-Google-Smtp-Source: AMrXdXsJJkfgk13o8UPO6z9RKijZkNb7xxs1sDZRTTRv1CN9BTb4dGGMVNmOkvMnUkhFIUnp5Y3VDWgkAvqdkfzwCnI= X-Received: by 2002:a05:651c:b1f:b0:28b:814d:7087 with SMTP id b31-20020a05651c0b1f00b0028b814d7087mr350271ljr.516.1673973844091; Tue, 17 Jan 2023 08:44:04 -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> <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> <20230113122246.uabdhut4ziwerivm@sirius.home.kraxel.org> <9141ad66-f868-762c-7ea5-d88753466fa6@redhat.com> <20230117123700.ntg5fk7a3ggr2xyo@sirius.home.kraxel.org> In-Reply-To: <20230117123700.ntg5fk7a3ggr2xyo@sirius.home.kraxel.org> From: "Ard Biesheuvel" Date: Tue, 17 Jan 2023 17:43:53 +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: Gerd Hoffmann Cc: Laszlo Ersek , devel@edk2.groups.io, Michael Brown , Ard Biesheuvel , Brijesh Singh , Erdem Aktas , James Bottomley , Jiewen Yao , Jordan Justen , Min Xu , Oliver Steffen , Sebastien Boeuf , Tom Lendacky Content-Type: text/plain; charset="UTF-8" On Tue, 17 Jan 2023 at 13:37, Gerd Hoffmann wrote: > > Hi, > > > >> In particular the firmware makes no further decisions based on > > >> whether QEMU advertized some of these features. > > > > > > I was thinking the other way around: When cpu hotplug is disabled in > > > qemu it should be safe to skip the whole cpu hotplug checking dance. > > > See test patch below. > > > > > > That would give us a config switch (turn off cpu hotplug support) > > > which would allow edk2 run on qemu versions with broken cpu hotplug. > > > > > > Does the idea look sane or do I miss something? > > > This would be wrong. > > > > [ detailed description snipped here (but stored for later reference, > > thanks for all the details) ] > > So, the tl;dr version: cpu hotplug is older than smi feature > negotiation, so smi hotplug feature bit being off doesn't imply > qemu wouldn't hotplug cpus. > > So, no easy way out. Luckily this affects tcg only. > > For edk2 ci doing (tcg) efi shell test boots switching to Oliver's > latest containers with fixed qemu included should handle things > (latest series just posted). So once this is in we should be able to > merge this patch without breaking CI. > My head is spinning. What about running QEMU with only a single CPU, and without any of these features? Is there really no way we can make that work without turning OVMF into the timebomb that Laszlo describes? It's just very annoying that on a non-KVM host and a given QEMU binary, you might simply be out of luck entirely, and there is no way you can run OVMF with the fix applied. I would like to avoid that if possible.