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.web12.5411.1648553460042010587 for ; Tue, 29 Mar 2022 04:31:00 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=APuw3Ku1; 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=1648553458; 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=fXs3M5e94ATjPSWFgg+k7fcBKcqctj24ol4Hj605BiA=; b=APuw3Ku1YDSaNK37oD7za/vG44NGBHGNU2lzWOKV/uisVHCdCkVOf0n9GXj0jWN48TBupV WERwFVvgEsU/nE6I394x4C/thQdnN2/kRDYeWYSV0pS0IvGEegPHQxOewJmpOwzzxJYu6Z 5A0CQcYX9CpHMvf2K0a3HBQUm1ZYU8A= 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-531-qCvklVrPOgqyb4pHf7Otow-1; Tue, 29 Mar 2022 07:30:55 -0400 X-MC-Unique: qCvklVrPOgqyb4pHf7Otow-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 822A9811E76; Tue, 29 Mar 2022 11:30:54 +0000 (UTC) Received: from sirius.home.kraxel.org (unknown [10.39.194.10]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 33A202166B3F; Tue, 29 Mar 2022 11:30:54 +0000 (UTC) Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id C836918003A3; Tue, 29 Mar 2022 13:30:52 +0200 (CEST) Date: Tue, 29 Mar 2022 13:30:52 +0200 From: "Gerd Hoffmann" To: Corvin =?utf-8?B?S8O2aG5l?= Cc: "devel@edk2.groups.io" , Ard Biesheuvel , Jiewen Yao , Jordan Justen , Rebecca Cran , Peter Grehan , FreeBSD Virtualization Subject: Re: [edk2-devel] [PATCH 0/1] OvmfPkg/Bhyve: QemuFwCfg support Message-ID: <20220329113052.pspiin3rvtnyygmb@sirius.home.kraxel.org> References: <20220329065437.186-1-c.koehne@beckhoff.com> <20220329091406.jp3e4bwdmyre6pnc@sirius.home.kraxel.org> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.78 on 10.11.54.6 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=kraxel@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit On Tue, Mar 29, 2022 at 09:57:40AM +0000, Corvin Köhne wrote: > Hi Gerd, > > > There is FW_CFG_NB_CPUS + FW_CFG_MAX_CPUS. ovmf uses different names, > > see OvmfPkg/Include/IndustryStandard/QemuFwCfg.h > > > > PlatformPei for qemu uses QemuFwCfgItemSmpCpuCount aka FW_CFG_NB_CPUS, > > which is the number of cpus which are online. > > > > I think FW_CFG_MAX_CPUS is basically unused these days. It played a > > role back when seabios created the acpi tables for cpu hotplug as > > described in the comment above. In qemu 2.0 & newer the acpi tables are > > generated by qemu instead. The firmware just downloads them from fw_cfg > > and installs them for the OS, it doesn't need to know virtual machine > > configuration details any more. > > The FwCfgItem of this patch is used by bhyve to build the MADT. So, it's > similar to the use case of FW_CFG_MAX_CPUS. At the moment, I'm using > an additional bhyve specific FwCfgItem. I just want to ask, if it makes sense > to use FW_CFG_MAX_CPUS to avoid two items for the same purpose or to > keep it as is. Given that FW_CFG_MAX_CPUS is unused on qemu these days it is unlikely that reusing it causes problems. IIRC the problems mentioned in the comment only matter with VMs having > 255 vCPUs because somewhere only one byte was used for the cpu / apic index. But I think I'd tend to keep the bhyve-specific behavior nevertheless, so you don't have to worry about qemu quirks. Or go the qemu route and generate the acpi tables on the host instead. When you generate the acpi tables in the guest firmware you always have the problem that you need to pass all the virtual machine configuration information needed to generate the tables to the firmware. The information needed changes over time when new features are added, which requires protocol updates, which in turn requires lockstep updates of hypervisor and firmware to deploy the new features ... HTH & take care, Gerd