From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38429) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UiOx8-0007Iv-2R for qemu-devel@nongnu.org; Fri, 31 May 2013 09:01:12 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UiOwz-0001vD-8C for qemu-devel@nongnu.org; Fri, 31 May 2013 09:01:05 -0400 Received: from mx1.redhat.com ([209.132.183.28]:38071) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UiOwy-0001v5-Qd for qemu-devel@nongnu.org; Fri, 31 May 2013 09:00:57 -0400 Message-ID: <51A89F96.4010901@redhat.com> Date: Fri, 31 May 2013 15:03:18 +0200 From: Laszlo Ersek MIME-Version: 1.0 References: <20130523124132.GA18596@redhat.com> <20130528235309.GA31648@morn.localdomain> <20130531023426.GB18156@morn.localdomain> <20130523124132.GA18596@redhat.com> <20130528235309.GA31648@morn.localdomain> <20130531023426.GB18156@morn.localdomain> <20130531081334.16432.qmail@stuge.se> In-Reply-To: <20130531081334.16432.qmail@stuge.se> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [SeaBIOS] KVM call agenda for 2013-05-28 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: KVM devel mailing list , seabios@seabios.org, qemu-devel qemu-devel On 05/31/13 10:13, Peter Stuge wrote: > ACPI bytes are obviously a function of QEMU configuration. Precisely! When we evaluate that (mathematical-sense) function in boot firmware, we need to retrieve the function's arguments. Those arguments are bits of QEMU configuration, as you say, and fw_cfg is extremely inconvenient for fetching them. Whenever the domain or arity of said "mathematical" function changes (we need more arguments, or different kinds of arguments), we have to extend fw_cfg with yet another ad-hoc key or file entry. The set of arguments going into ACPI tables *is* ad-hoc and arbitrary, there's nothing to do about it. But at least we shouldn't impede the retrieval of said arguments with artificial obstacles, such as half-assedly serializing them over fw_cfg (and not documenting them, naturally). In qemu the entire pool of arguments, current and future, would be at just an arm's length, in immediately consumable form. I've said the same about the acpi_build_madt() prototype that was proposed for qemu: . Thanks, Laszlo