From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from netsrv01.beckhoff.com (netsrv01.beckhoff.com [62.159.14.10]) by mx.groups.io with SMTP id smtpd.web10.5717.1648554793497150925 for ; Tue, 29 Mar 2022 04:53:14 -0700 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: beckhoff.com, ip: 62.159.14.10, mailfrom: 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: =?UTF-8?B?Q29ydmluIEvDtmhuZQ==?= 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 X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [94.134.181.69] x-olx-disclaimer: EX03.BECKHOFF.COM MIME-Version: 1.0 Content-Language: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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