From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49548) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XmGyR-0006az-GW for qemu-devel@nongnu.org; Thu, 06 Nov 2014 01:55:21 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XmGyL-0001s8-AE for qemu-devel@nongnu.org; Thu, 06 Nov 2014 01:55:15 -0500 Received: from mail-pd0-f178.google.com ([209.85.192.178]:63437) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XmGyL-0001rY-53 for qemu-devel@nongnu.org; Thu, 06 Nov 2014 01:55:09 -0500 Received: by mail-pd0-f178.google.com with SMTP id fp1so579466pdb.9 for ; Wed, 05 Nov 2014 22:55:07 -0800 (PST) Message-ID: <545B1ACF.4090600@linaro.org> Date: Thu, 06 Nov 2014 14:53:03 +0800 From: Hanjun Guo MIME-Version: 1.0 References: <1414691045-4793-1-git-send-email-a.spyridakis@virtualopensystems.com> <20141030180216.GD31629@leverpostej> In-Reply-To: <20141030180216.GD31629@leverpostej> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Mark Rutland , Peter Maydell Cc: "tech@virtualopensystems.com" , QEMU Developers , "linaro-acpi@lists.linaro.org" On 2014-10-31 2:02, Mark Rutland wrote: > On Thu, Oct 30, 2014 at 05:52:44PM +0000, Peter Maydell wrote: >> On 30 October 2014 17:43, Alexander Spyridakis >> wrote: >>> Currently, the virt machine model generates Device Tree information dynamically based on the existing devices in the system. This patch series extends the same concept but for ACPI information instead. A total of seven tables have been >>> implemented in this patch series, which is the minimum for a basic ARM support. >>> >>> The set of generated tables are: >>> - RSDP >>> - XSDT >>> - MADT >>> - GTDT >>> - FADT >>> - FACS >>> - DSDT >>> >>> The tables are created in standalone buffers, taking into account the >>> needed information passed from the virt machine model. When the generation >>> is finalized, the individual buffers are compacted to a single ACPI binary >>> blob, where it is injected on the guest memory space in a fixed location. >>> The guest kernel can find the ACPI tables by providing to it the physical >>> address of the ACPI blob (e.g. acpi_rsdp=0x47000000 boot argument). >> >> (Sorry, I should have waited for the cover letter to arrive before replying.) >> >> I think this is definitely the wrong approach. We already have to >> generate device tree information for the hardware we have, and having >> an equivalent parallel infrastructure for generating ACPI as well >> seems like it would be a tremendous mess. We should support guests >> that require ACPI by having QEMU boot a UEFI bios blob and have that >> UEFI code generate ACPI tables based on the DTB we hand it. >> (Chances seem good that any guest that wants ACPI is going to want >> UEFI runtime services anyway.) > > Depending on why people want ACPI in a guest environment, generating > ACPI tables from a DTB might not be possible (e.g. if they want to use > AML for some reason). Agreed. > > So the important question is _why_ the guest needs to see an ACPI > environment. What exactly can ACPI provide to the guest that DT does not > already provide, and why is that necessary? What infrastrucutre is > needed for that use case? There is important feature called system device dynamic reconfiguration, you know, hot-add/remove, if a gust need more/less memory or CPU, can we add or remove them dynamically with DT? ACPI can do this, but I have no idea if DT can. (Sorry, I don't know much about DT) Thanks Hanjun