From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56217) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V2eXx-0001fU-Go for qemu-devel@nongnu.org; Fri, 26 Jul 2013 05:42:50 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V2eXw-00006W-Lv for qemu-devel@nongnu.org; Fri, 26 Jul 2013 05:42:49 -0400 Received: from mx1.redhat.com ([209.132.183.28]:60942) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V2eXw-00006K-F5 for qemu-devel@nongnu.org; Fri, 26 Jul 2013 05:42:48 -0400 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r6Q9glN4030014 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 26 Jul 2013 05:42:48 -0400 Message-ID: <51F24495.9030403@redhat.com> Date: Fri, 26 Jul 2013 11:42:45 +0200 From: Gerd Hoffmann MIME-Version: 1.0 References: <1374681580-17439-1-git-send-email-mst@redhat.com> <1374681580-17439-7-git-send-email-mst@redhat.com> In-Reply-To: <1374681580-17439-7-git-send-email-mst@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v3 06/14] i386: add bios linker/loader List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: qemu-devel@nongnu.org Hi, Hacked up coreboot support to verify the interface. > + /* > + * COMMAND_ALLOCATE - allocate a table from @alloc_file > + * subject to @alloc_align alignment (must be power of 2) > + * and @alloc_zone (can be HIGH or FSEG) requirements. > + * > + * Must appear exactly once for each file, and before > + * this file is referenced by any other command. > + */ Do we need alloc_zone? Rules are simple: rsdp goes to fseg, everything else to high, correct? Both seabios and coreboot handle that by first placing *all* acpi tables in high memory, then go place a rsdp copy in fseg. > + /* > + * COMMAND_ADD_POINTER - patch the table (originating from > + * @dest_file) at @pointer_offset, by adding a pointer to the table > + * originating from @src_file. 1,2,4 or 8 byte unsigned > + * addition is used depending on @pointer_size. > + */ Do we need pointer_size? Current tables use 4 bytes only. 1+2 bytes is pointless, the src_file address will be big enougth that it doesn't fit into one or two bytes, so I doubt they will ever be used. 8 bytes would only be used when placing acpi tables above 4g. Is that something expected to happen? If not 4 bytes is enough, even for 8 byte pointers as the 4 high bytes would be zero no matter what. cheers, Gerd