From nobody Sat Oct 16 08:37:54 2021 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 14362180719D for ; Sat, 16 Oct 2021 08:38:08 +0000 (UTC) (envelope-from SRS0=yYI6=PE=freebsd.org=grehan@iredmail.onthenet.com.au) Received: from alto.onthenet.com.au (alto.OntheNet.com.au [203.13.68.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4HWc3L3bSRz4kft for ; Sat, 16 Oct 2021 08:38:05 +0000 (UTC) (envelope-from SRS0=yYI6=PE=freebsd.org=grehan@iredmail.onthenet.com.au) Received: from iredmail.onthenet.com.au (iredmail.onthenet.com.au [203.13.68.150]) by alto.onthenet.com.au (Postfix) with ESMTPS id 90BFF20B49E6 for ; Sat, 16 Oct 2021 18:37:55 +1000 (AEST) Received: from iredmail.onthenet.com.au (iredmail.onthenet.com.au [127.0.0.1]) by iredmail.onthenet.com.au (Postfix) with ESMTP id 87E7A20B49B6 for ; Sat, 16 Oct 2021 18:37:55 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nt.com.au; h= content-transfer-encoding:content-language:content-type :content-type:in-reply-to:mime-version:user-agent:date:date :message-id:from:from:references:to:subject:subject; s=dkim; t= 1634373475; x=1636965476; bh=ogOcUyghvdlB9dlxXDkJ3iP41pKgCUURCYI WZ5pHAfw=; b=ds2LtGragDdSPBS5q0ouwoq+xKNw1nyUiOkzNzuVRM87O66mE4F v5gWV2Me6qwzCXhJy9hsz8R3RFb5/4Z2nuGzQ9DnmeDA0579xKcLlsiQcaU9vbq3 Am5dKKfVx7LqbijchZAB9j8mknKVyqExehS7iYCpqj6F+kVjfgKsWq9Y= Received: from iredmail.onthenet.com.au ([127.0.0.1]) by iredmail.onthenet.com.au (iredmail.onthenet.com.au [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id M8-xOB0RZtJU for ; Sat, 16 Oct 2021 18:37:55 +1000 (AEST) Received: from MacBook-Air-4.local (CPE-120-29-50-221.dsl.OntheNet.net [120.29.50.221]) by iredmail.onthenet.com.au (Postfix) with ESMTPSA id 533C120B49B3; Sat, 16 Oct 2021 18:37:55 +1000 (AEST) Subject: Re: [PATCH] OvmfPkg/Bhyve: install bhyve's ACPI tables To: =?UTF-8?Q?Corvin_K=c3=b6hne?= Cc: FreeBSD Virtualization References: <20211014071056.452-1-c.koehne@beckhoff.com> From: Peter Grehan Message-ID: <39f6e329-2d8a-2fa7-cd39-5031d6646b9f@freebsd.org> Date: Sat, 16 Oct 2021 18:37:54 +1000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 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 In-Reply-To: <20211014071056.452-1-c.koehne@beckhoff.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-CMAE-Score: 0 X-CMAE-Analysis: v=2.3 cv=ONO8IRSB c=1 sm=1 tr=0 a=A6CF0fG5TOl4vs6YHvqXgw==:117 a=lvEwUD+J6oDjjCrxL21sGw==:17 a=IkcTkHD0fZMA:10 a=8gfv0ekSlNoA:10 a=NEAV23lmAAAA:8 a=qO2m75UGKiCQLCtN3y0A:9 a=QEXdDO2ut3YA:10 X-Rspamd-Queue-Id: 4HWc3L3bSRz4kft X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=nt.com.au header.s=dkim header.b=ds2LtGra; dmarc=none; spf=none (mx1.freebsd.org: domain of "SRS0=yYI6=PE=freebsd.org=grehan@iredmail.onthenet.com.au" has no SPF policy when checking 203.13.68.12) smtp.mailfrom="SRS0=yYI6=PE=freebsd.org=grehan@iredmail.onthenet.com.au" X-Spamd-Result: default: False [-3.09 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_FIVE(0.00)[5]; R_DKIM_ALLOW(-0.20)[nt.com.au:s=dkim]; FROM_HAS_DN(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[203.13.68.12:from]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-virtualization@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[nt.com.au:+]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.99)[-0.987]; R_SPF_NA(0.00)[no SPF record]; FORGED_SENDER(0.30)[grehan@freebsd.org,SRS0=yYI6=PE=freebsd.org=grehan@iredmail.onthenet.com.au]; RCVD_IN_DNSWL_LOW(-0.10)[203.13.68.12:from]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:9313, ipnet:203.13.68.0/23, country:AU]; FROM_NEQ_ENVFROM(0.00)[grehan@freebsd.org,SRS0=yYI6=PE=freebsd.org=grehan@iredmail.onthenet.com.au]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Hi Corvin K=C3=B6hne wrote:, > =EF=BB=BFIt's much easier to create configuration dependend ACPI tables= for > bhyve than for OVMF. For this reason, don't use the statically > created ACPI tables provided by OVMF. Instead use the dynamically > created ACPI tables of bhyve. If bhyve provides no ACPI tables or > we are unable to detect those, fall back to OVMF tables. Thanks for forwarding this to the list. I think it's an interesting change - fortunately it is opt-in for EFI=20 users since they generally run without the -A option, which will=20 continue to allow ACPI tables to be created from within EFI. There will be some issues with the use of this that may have to be=20 addressed at some point - the PCI mmio/io windows are created assuming that bhyve has done PCI=20 enumeration. If EFI is doing enumeration, these will be incorrect - the SPCR isn't generated by bhyve, but is by EFI. There are Windows=20 users who rely on having a serial console, so this should be added to=20 bhyve. Fortunately the table is trivial. - the space used by bhyve ACPI tables (the area just below 1MB=20 physical) is quite small and has little room for expansion. Qemu gets=20 around this by providing ACPI tables (or just the DSDT) by a fw_cfg=20 interface, and doesn't place the tables into RAM. There are other more general issues with bhyve ACPI. Fork/exec of iasl=20 is convenient, and guarantees tables are syntactically correct, but is=20 expensive in startup time. It would be preferable for tables to be=20 generated without iasl. This is simple for static tables, but for=20 DSDT/SSDT, something like EDK2's dynamic table generation could be used=20 (https://github.com/tianocore/edk2/tree/master/DynamicTablesPkg) I also feel that table generation in EFI is still a viable approach,=20 though it requires additional information to be pass from the=20 hypervisor, and dynamic table generation, to get to feature parity with=20 bhyve's generated tables. later, Peter.