From nobody Tue Mar 29 11:53:09 2022 X-Original-To: freebsd-virtualization@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4610E1A406DC for ; Tue, 29 Mar 2022 11:53:14 +0000 (UTC) (envelope-from C.Koehne@beckhoff.com) Received: from netsrv01.beckhoff.com (netsrv01.beckhoff.com [62.159.14.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "*.beckhoff.com", Issuer "Thawte TLS RSA CA G1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KSScn1DRdz4hZL; Tue, 29 Mar 2022 11:53:13 +0000 (UTC) (envelope-from C.Koehne@beckhoff.com) Received: from 172.17.2.169 by netsrv01.beckhoff.com (Tls12, Aes256, Sha384, DiffieHellmanEllipticKey256); Tue, 29 Mar 2022 11:53:12 GMT Received: from ex04.beckhoff.com (172.17.5.170) by ex03.beckhoff.com (172.17.2.169) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2375.24; Tue, 29 Mar 2022 13:53:10 +0200 Received: from ex04.beckhoff.com ([fe80::c545:54e6:8481:2958]) by ex04.beckhoff.com ([fe80::c545:54e6:8481:2958%6]) with mapi id 15.01.2375.024; Tue, 29 Mar 2022 13:53:10 +0200 From: =?iso-8859-1?Q?Corvin_K=F6hne?= To: Gerd Hoffmann 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 Thread-Topic: [edk2-devel] [PATCH 0/1] OvmfPkg/Bhyve: QemuFwCfg support Thread-Index: AQHYQznukcp63DlJJUmrp70bhBsgI6zV8rMAgAAsAuD///o0AIAAJMig Date: Tue, 29 Mar 2022 11:53:09 +0000 Message-ID: <02bd2bef03484e189f04dc39a6f3ad66@beckhoff.com> References: <20220329065437.186-1-c.koehne@beckhoff.com> <20220329091406.jp3e4bwdmyre6pnc@sirius.home.kraxel.org> <20220329113052.pspiin3rvtnyygmb@sirius.home.kraxel.org> In-Reply-To: <20220329113052.pspiin3rvtnyygmb@sirius.home.kraxel.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [94.134.181.69] x-olx-disclaimer: EX03.BECKHOFF.COM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable List-Id: Discussion List-Archive: https://lists.freebsd.org/archives/freebsd-virtualization List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-virtualization@freebsd.org X-BeenThere: freebsd-virtualization@freebsd.org MIME-Version: 1.0 X-Rspamd-Queue-Id: 4KSScn1DRdz4hZL X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of C.Koehne@beckhoff.com designates 62.159.14.10 as permitted sender) smtp.mailfrom=C.Koehne@beckhoff.com X-Spamd-Result: default: False [-1.80 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; HAS_XOIP(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; RCVD_COUNT_THREE(0.00)[4]; NEURAL_HAM_SHORT(-1.00)[-0.997]; RCPT_COUNT_SEVEN(0.00)[8]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:3320, ipnet:62.156.0.0/14, country:DE]; RCVD_TLS_LAST(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; TAGGED_RCPT(0.00)[tianocore]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[beckhoff.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MLMMJ_DEST(0.00)[freebsd-virtualization]; SUSPICIOUS_RECIPS(1.50)[] X-ThisMailContainsUnwantedMimeParts: N Hi Gerd, > But I think I'd tend to keep the bhyve-specific behavior nevertheless, > so you don't have to worry about qemu quirks. Ok. I will leave it as is. > 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 ... Personally, I would like to use plain OVMF without any bhyve specific patch= es as firmware for bhyve. So, I want to go the qemu route but there's some mor= e work to do. I already took a look at how qemu creates ACPI tables but don't understand it yet. Would be very grateful if you or someone else could help me with that. If someone knows where to find more information about it, it would also be helpful. As first step, I'm going to implement FwCfg support without changing any behaviour. Thanks, Corvin Beckhoff Automation GmbH & Co. KG | Managing Director: Dipl. Phys. Hans Bec= khoff Registered office: Verl, Germany | Register court: Guetersloh HRA 7075