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.web10.53298.1681733672041001564 for ; Mon, 17 Apr 2023 05:14:32 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=SH0nKUx9; 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=1681733671; 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=Y4kDtXuAn80jd11fSm9+Dm2d5WeuDd33qr/XtiJ3FnA=; b=SH0nKUx9fIx/Zp0K9t8z/j8rhPpmw8Cd8KvGlgMIpRNzoikhNC8Yo/owOQvdbv4LA8BM0p ZfdWCDGDVcqQUa5JasBSuVFligLlYiqrRwYUHLYMXES3w/dLNTtkgNGoBw9neCRPKG2tVS 0EwSTMKYGp24faK52aQh9/i/JMixj30= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-387-fj0lSK0ZNmqjkPGB2nxZKw-1; Mon, 17 Apr 2023 08:14:29 -0400 X-MC-Unique: fj0lSK0ZNmqjkPGB2nxZKw-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 4F25728237CB; Mon, 17 Apr 2023 12:14:29 +0000 (UTC) Received: from sirius.home.kraxel.org (unknown [10.39.193.149]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 97E7E2027044; Mon, 17 Apr 2023 12:14:28 +0000 (UTC) Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id 2E19218000B3; Mon, 17 Apr 2023 14:14:27 +0200 (CEST) Date: Mon, 17 Apr 2023 14:14:27 +0200 From: "Gerd Hoffmann" To: Corvin =?utf-8?B?S8O2aG5l?= Cc: devel@edk2.groups.io, Michael D Kinney , Liming Gao , Zhiguang Liu , Ard Biesheuvel , Jiewen Yao , Jordan Justen , Rebecca Cran , Peter Grehan Subject: Re: [PATCH 1/1] OvmfPkg/BhyveBhf: install bhyve's ACPI tables Message-ID: References: <20230417114601.398383-1-corvink@FreeBSD.org> MIME-Version: 1.0 In-Reply-To: <20230417114601.398383-1-corvink@FreeBSD.org> X-Scanned-By: MIMEDefang 3.1 on 10.11.54.4 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 Mon, Apr 17, 2023 at 01:46:01PM +0200, Corvin Köhne wrote: > It'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 prefer 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. > > Ideally, we use the qemu fwcfg interface to pass the ACPI tables from > bhyve to OVMF. bhyve will support this in the future. However, current > bhyve executables don't support passing ACPI tables by the qemu fwcfg > interface. They just copy the ACPI into main memory. For that reason, > pick up the ACPI tables from main memory. > > Implementation is similar to OvmfPkg/XenAcpiPlatformDxe/Xen.c. Can both Xen and Bhyve share the same implementation? Given in both cases RAM is scanned for the RSDP I'd expect it should not be very hard and we avoid duplicating the code. take care, Gerd