From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:40372)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <a.spyridakis@virtualopensystems.com>)
	id 1XmNBp-0007A3-EP
	for qemu-devel@nongnu.org; Thu, 06 Nov 2014 08:33:35 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <a.spyridakis@virtualopensystems.com>)
	id 1XmNBj-0003mb-Gz
	for qemu-devel@nongnu.org; Thu, 06 Nov 2014 08:33:29 -0500
Received: from mail-qa0-f45.google.com ([209.85.216.45]:44972)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <a.spyridakis@virtualopensystems.com>)
	id 1XmNBj-0003lw-DE
	for qemu-devel@nongnu.org; Thu, 06 Nov 2014 08:33:23 -0500
Received: by mail-qa0-f45.google.com with SMTP id dc16so710160qab.32
	for <qemu-devel@nongnu.org>; Thu, 06 Nov 2014 05:33:22 -0800 (PST)
Received: from mail-yh0-f54.google.com (mail-yh0-f54.google.com.
	[209.85.213.54])
	by mx.google.com with ESMTPSA id i1sm5872346qaz.28.2014.11.06.05.33.21
	for <qemu-devel@nongnu.org>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Thu, 06 Nov 2014 05:33:21 -0800 (PST)
Received: by mail-yh0-f54.google.com with SMTP id t59so1361330yho.27
	for <qemu-devel@nongnu.org>; Thu, 06 Nov 2014 05:33:20 -0800 (PST)
MIME-Version: 1.0
In-Reply-To: <CAFEAcA82TM_37WTJ1Rw4vmk_4zuJ2no2=A4bCg=0qhJqtJxmOA@mail.gmail.com>
References: <1414691045-4793-1-git-send-email-a.spyridakis@virtualopensystems.com>
	<CAFEAcA-Fe0Q4FM-Ck2+YjmDiM3ivmFSN6g-nbo-zTxo9e=s=hg@mail.gmail.com>
	<20141030180216.GD31629@leverpostej> <5459F4CB.1000009@huawei.com>
	<CAFEAcA82TM_37WTJ1Rw4vmk_4zuJ2no2=A4bCg=0qhJqtJxmOA@mail.gmail.com>
Date: Thu, 6 Nov 2014 15:33:20 +0200
Message-ID: <CAJRNFK+vgdNs608+AbHHaNjpHtPgfeRKyzYdW64DDmirKOFRyw@mail.gmail.com>
From: Alexander Spyridakis <a.spyridakis@virtualopensystems.com>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic
 ACPI v5.1 table generation
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: Mark Rutland <mark.rutland@arm.com>, "linaro-acpi@lists.linaro.org" <linaro-acpi@lists.linaro.org>, Alexander Spyridakis <a.spyridakis@virtualopensystems.com>, Claudio Fontana <claudio.fontana@huawei.com>, QEMU Developers <qemu-devel@nongnu.org>, "tech@virtualopensystems.com" <tech@virtualopensystems.com>

On 6 November 2014 14:44, Peter Maydell <peter.maydell@linaro.org> wrote:
>
>
> > We need ACPI guest support in QEMU for AArch64 over here, with all features
> > (including the ability to run ACPI code and add specific tables), for
> > ACPI-based guests.
>
> The plan for providing ACPI to guests is that we run a UEFI BIOS
> blob which is what is responsible for providing ACPI and UEFI
> runtime services to guests which need them. (The UEFI blob finds
> out about its hardware by looking at a device tree that QEMU
> passes it, but that's a detail between QEMU and its bios blob).
> This pretty much looks like what x86 QEMU used to do with ACPI
> for a very long time, so we know it's a feasible approach.

Hi Peter,

The rational in the proposed approach is meant for cases where the
user does not want to rely on external firmware layers. While UEFI
could do what you are describing, the point is to avoid this not so
trivial overhead in the booting process. Especially in the case of
thin guests, where another software dependency is undesired.

Regards.