From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34830) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YgFDa-0003oX-SE for qemu-devel@nongnu.org; Thu, 09 Apr 2015 12:22:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YgFDY-0003SM-B7 for qemu-devel@nongnu.org; Thu, 09 Apr 2015 12:22:14 -0400 Received: from mx1.redhat.com ([209.132.183.28]:55966) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YgFDY-0003SB-4Z for qemu-devel@nongnu.org; Thu, 09 Apr 2015 12:22:12 -0400 Message-ID: <5526A723.9030207@redhat.com> Date: Thu, 09 Apr 2015 18:21:55 +0200 From: Laszlo Ersek MIME-Version: 1.0 References: <1428055432-12120-1-git-send-email-zhaoshenglong@huawei.com> <1428055432-12120-11-git-send-email-zhaoshenglong@huawei.com> <877ftl1n4j.fsf@linaro.org> <20150409151718.5eb49015@nial.brq.redhat.com> <20150409155119.0cf5bc94@nial.brq.redhat.com> <5526A204.8060802@redhat.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH v4 10/20] hw/arm/virt-acpi-build: Generate RSDT table List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: hangaohuai@huawei.com, "Michael S. Tsirkin" , Alexander Spyridakis , Shannon Zhao , Claudio Fontana , QEMU Developers , "Huangpeng (Peter)" , Paolo Bonzini , Hanjun Guo , Mark Salter , Igor Mammedov , =?UTF-8?B?QWxleCBCZW5uw6ll?= , Christoffer Dall , Shannon Zhao On 04/09/15 18:03, Peter Maydell wrote: > On 9 April 2015 at 17:00, Laszlo Ersek wrote: >> On 04/09/15 15:59, Peter Maydell wrote: >>> On 9 April 2015 at 14:51, Igor Mammedov wrote: >>>> On Thu, 9 Apr 2015 14:27:58 +0100 >>>> Peter Maydell wrote: >>>> >>>>> On 9 April 2015 at 14:17, Igor Mammedov wrote= : >>>>>> On Thu, 09 Apr 2015 13:50:52 +0100 >>>>>> Alex Benn=C3=A9e wrote: >>>>>> >>>>>>> >>>>>>> Shannon Zhao writes: >>>>>>>> + for (i =3D 0; i < table_offsets->len; ++i) { >>>>>>>> + /* rsdt->table_offset_entry to be filled by Guest linke= r */ >>>>>>>> + bios_linker_loader_add_pointer(linker, >>>>>>>> + ACPI_BUILD_TABLE_FILE, >>>>>>>> + ACPI_BUILD_TABLE_FILE, >>>>>>>> + table_data, &rsdt->table= _offset_entry[i], >>>>>>>> + sizeof(uint32_t)); >>>>>>> >>>>>>> Why are these pointers always 32 bit? Can they ever be 64 bit? >>>>>> Laszlo, can you confirm that UEFI puts APCI tables below 4G addres= s >>>>>> space? >> >> I confirmed that before, in the v2 discussion: >> >> http://thread.gmane.org/gmane.comp.emulators.qemu/316670/focus=3D31756= 0 >> >> But in fact the RSDT / XSDT that QEMU exports for UEFI doesn't matter. >=20 > If this table is never used, presumably we should just > not generate it at all, then? Unfortunately, this is not the case. In order to identify ACPI tables *at= all* in UEFI, I need "relocate pointer" commands for pointers that point= to those tables. And those pointers must *reside* somewhere, in some blo= b. Here's how the "relocate pointer" command is defined in edk2 (OvmfPkg/Acp= iPlatformDxe/QemuLoader.h): // // QemuLoaderCmdAddPointer: the bytes at // [PointerOffset..PointerOffset+PointerSize) in the file PointerFile con= tain a // relative pointer (an offset) into PointeeFile. Increment the relative // pointer's value by the base address of where PointeeFile's contents ha= ve // been placed (when QemuLoaderCmdAllocate has been executed for PointeeF= ile). // typedef struct { UINT8 PointerFile[QEMU_LOADER_FNAME_SIZE]; // NUL-terminated UINT8 PointeeFile[QEMU_LOADER_FNAME_SIZE]; // NUL-terminated UINT32 PointerOffset; UINT8 PointerSize; // one of 1, 2, 4, 8 } QEMU_LOADER_ADD_POINTER; In the qemu tree, see COMMAND_ADD_POINTER in "hw/acpi/bios-linker-loader.= c", for the same. (I rewrote the types and the comments in edk2 from scra= tch, both for coding style reasons and for clearer documentation.) ... To be clear: the top-level pointers must exist somewhere (in some blo= b), because that helps edk2 find the tables (in some other blobs). Howeve= r, the top-level pointers themselves don't need to reside in any ACPI tab= le (RSDT, XSDT); they can just live in an otherwise unreferenced portion = of one of the blobs. But, IMO, implementing that wouldn't be much easier (and it would certain= ly be uglier) than composing a correct RSDT or XSDT. The latter would als= o keep the similarity with the x86 SeaBIOS case (where the RSDT is a hard= requirement). Thanks Laszlo