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.10288.1674026735519391948 for ; Tue, 17 Jan 2023 23:25:35 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=QzEJQaEs; spf=pass (domain: redhat.com, ip: 170.10.129.124, mailfrom: kraxel@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1674026734; 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: in-reply-to:in-reply-to:references:references; bh=mTXSBmRikLnZeSJvz/fYaEW8Hfgi7XczgU7QOycF/XI=; b=QzEJQaEs23as2qk3gGI3HPbyYdEfHbCDOuMY7WSZ7ezrwSaAdi9NuzIFK/2BD4CiziZZxt u7a9QFReJh96EztqSyFPAIfMQo5hiCwSQRvxLAaIEf7r4Xy3qQ6yF1UTfITqJGuu4eyeWl cw93tKxxP0VRlA+0Rp6HqKmEj8QEhTY= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-673-ugL_PY68Pni9k4g2yLTDug-1; Wed, 18 Jan 2023 02:25:28 -0500 X-MC-Unique: ugL_PY68Pni9k4g2yLTDug-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.rdu2.redhat.com [10.11.54.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 53991183B3C1; Wed, 18 Jan 2023 07:25:27 +0000 (UTC) Received: from sirius.home.kraxel.org (unknown [10.39.192.186]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 132C0C15BAD; Wed, 18 Jan 2023 07:25:27 +0000 (UTC) Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id AD51C1800091; Wed, 18 Jan 2023 08:25:25 +0100 (CET) Date: Wed, 18 Jan 2023 08:25:25 +0100 From: "Gerd Hoffmann" To: Ard Biesheuvel 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 Subject: Re: [edk2-devel] [PATCH v2] OvmfPkg/PlatformInitLib: catch QEMU's CPU hotplug reg block regression Message-ID: <20230118072525.cnk5ysqcnvdyeqow@sirius.home.kraxel.org> References: <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> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 3.1 on 10.11.54.8 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Jan 17, 2023 at 05:43:53PM +0100, Ard Biesheuvel wrote: > 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? I can't see any way :( ovmf seeing only a single cpu does not imply cpu hotplug can't happen, it could be "qemu -smp cpus=1,maxcpus=4". Figuring the maxcpus number depends on the broken cpu hotplug registers. > 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. Indeed. take care, Gerd