From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=209.132.183.28; helo=mx1.redhat.com; envelope-from=lersek@redhat.com; receiver=edk2-devel@lists.01.org Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 476D321195BF8 for ; Tue, 27 Nov 2018 03:23:19 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id B9AE615552; Tue, 27 Nov 2018 11:23:18 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-120-96.rdu2.redhat.com [10.10.120.96]) by smtp.corp.redhat.com (Postfix) with ESMTP id D2D715C1B2; Tue, 27 Nov 2018 11:23:08 +0000 (UTC) To: =?UTF-8?Q?Philippe_Mathieu-Daud=c3=a9?= , edk2-devel@lists.01.org Cc: Anthony Perard , Ard Biesheuvel , Drew Jones , Igor Mammedov , Jordan Justen , Julien Grall References: <20181125100152.25675-1-lersek@redhat.com> <20181125100152.25675-2-lersek@redhat.com> <8dcb0e57-cfde-8eea-938d-753320d0c031@redhat.com> From: Laszlo Ersek Message-ID: <35f899c1-304d-23b5-95c8-cd634f5fcb6c@redhat.com> Date: Tue, 27 Nov 2018 12:23:07 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <8dcb0e57-cfde-8eea-938d-753320d0c031@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Tue, 27 Nov 2018 11:23:18 +0000 (UTC) Subject: Re: [PATCH 1/4] OvmfPkg: introduce ACPI Test Support data structure and GUID X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2018 11:23:19 -0000 X-List-Received-Date: Tue, 27 Nov 2018 11:23:19 -0000 X-List-Received-Date: Tue, 27 Nov 2018 11:23:19 -0000 X-List-Received-Date: Tue, 27 Nov 2018 11:23:19 -0000 X-List-Received-Date: Tue, 27 Nov 2018 11:23:19 -0000 X-List-Received-Date: Tue, 27 Nov 2018 11:23:19 -0000 X-List-Received-Date: Tue, 27 Nov 2018 11:23:19 -0000 X-List-Received-Date: Tue, 27 Nov 2018 11:23:19 -0000 X-List-Received-Date: Tue, 27 Nov 2018 11:23:19 -0000 X-List-Received-Date: Tue, 27 Nov 2018 11:23:19 -0000 X-List-Received-Date: Tue, 27 Nov 2018 11:23:19 -0000 X-List-Received-Date: Tue, 27 Nov 2018 11:23:19 -0000 X-List-Received-Date: Tue, 27 Nov 2018 11:23:19 -0000 X-List-Received-Date: Tue, 27 Nov 2018 11:23:19 -0000 X-List-Received-Date: Tue, 27 Nov 2018 11:23:19 -0000 X-List-Received-Date: Tue, 27 Nov 2018 11:23:19 -0000 X-List-Received-Date: Tue, 27 Nov 2018 11:23:19 -0000 X-List-Received-Date: Tue, 27 Nov 2018 11:23:19 -0000 X-List-Received-Date: Tue, 27 Nov 2018 11:23:19 -0000 X-List-Received-Date: Tue, 27 Nov 2018 11:23:19 -0000 X-List-Received-Date: Tue, 27 Nov 2018 11:23:19 -0000 X-List-Received-Date: Tue, 27 Nov 2018 11:23:19 -0000 X-List-Received-Date: Tue, 27 Nov 2018 11:23:19 -0000 X-List-Received-Date: Tue, 27 Nov 2018 11:23:19 -0000 X-List-Received-Date: Tue, 27 Nov 2018 11:23:19 -0000 X-List-Received-Date: Tue, 27 Nov 2018 11:23:19 -0000 X-List-Received-Date: Tue, 27 Nov 2018 11:23:19 -0000 X-List-Received-Date: Tue, 27 Nov 2018 11:23:19 -0000 X-List-Received-Date: Tue, 27 Nov 2018 11:23:19 -0000 X-List-Received-Date: Tue, 27 Nov 2018 11:23:19 -0000 X-List-Received-Date: Tue, 27 Nov 2018 11:23:19 -0000 X-List-Received-Date: Tue, 27 Nov 2018 11:23:19 -0000 X-List-Received-Date: Tue, 27 Nov 2018 11:23:19 -0000 X-List-Received-Date: Tue, 27 Nov 2018 11:23:19 -0000 X-List-Received-Date: Tue, 27 Nov 2018 11:23:19 -0000 X-List-Received-Date: Tue, 27 Nov 2018 11:23:19 -0000 X-List-Received-Date: Tue, 27 Nov 2018 11:23:19 -0000 X-List-Received-Date: Tue, 27 Nov 2018 11:23:19 -0000 X-List-Received-Date: Tue, 27 Nov 2018 11:23:19 -0000 X-List-Received-Date: Tue, 27 Nov 2018 11:23:19 -0000 X-List-Received-Date: Tue, 27 Nov 2018 11:23:19 -0000 X-List-Received-Date: Tue, 27 Nov 2018 11:23:19 -0000 X-List-Received-Date: Tue, 27 Nov 2018 11:23:19 -0000 X-List-Received-Date: Tue, 27 Nov 2018 11:23:19 -0000 X-List-Received-Date: Tue, 27 Nov 2018 11:23:19 -0000 X-List-Received-Date: Tue, 27 Nov 2018 11:23:19 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit On 11/26/18 22:43, Philippe Mathieu-Daudé wrote: > Hi Laszlo, > > On 25/11/18 11:01, Laszlo Ersek wrote: >> QEMU's test suite includes a set of cases called "BIOS tables test". Among >> other things, it locates the RSD PTR ACPI table in guest RAM, and then >> (chasing pointers to other ACPI tables) performs various sanity checks on >> the QEMU-generated and firmware-installed tables. >> >> Currently this set of test cases doesn't work with UEFI guests, because >> the ACPI spec's definition for locating the RSD PTR in UEFI guests is a >> lot harder to implement from the hypervisor side -- just with raw guest >> memory access -- than it is when scraping the memory of BIOS guests. >> >> Introduce a signature GUID, and a small, MB-aligned structure, identified >> by the GUID. The hypervisor should loop over all MB-aligned pages in guest >> RAM until one matches the signature GUID at offset 0, at which point the >> hypervisor can fetch the RSDP address field(s) from the structure. >> >> QEMU's test logic currently spins on a pre-determined guest address, until >> that address assumes a magic value. The method described in this patch is >> conceptually the same ("busy loop until match is found"), except there is >> no hard-coded address. This plays a lot more nicely with UEFI guest >> firmware (we'll be able to use the normal page allocation UEFI service). >> Given the size of EFI_GUID (16 bytes -- 128 bits), mismatches should be >> astronomically unlikely. In addition, given the typical guest RAM size for >> such tests (128 MB), there are 128 locations to check in one iteration of >> the "outer" loop, which shouldn't introduce an intolerable delay after the >> guest stores the RSDP address(es), and then the GUID. > > I applied/build your series, OK. > but keep failing trying to test it with QEMU :/ Hm. > I modified a bit tests/bios-tables-test.c to use the OVMF.fd build for > the Q35 machine tests, OK. The primary goal of this series is to enable QEMU developers to extend bios-tables-test.c to "qemu-system-aarch64/virt"; but, indeed, I intend the firmware feature to be platform-independent. Instead, it's the QEMU test case that is supposed to know, intimately, the subject physical memory map (that is: the set of locations in guest-phys mem address space that are 1MB aligned and are actually DRAM-backed). So where exactly to probe is up to QEMU / qtest. > but still pass the "OnRootBridgesConnected: root > bridges have been connected, installing ACPI tables". Sorry, I don't understand this. What do you mean by "still pass"? AcpiPlatformDxe will print the message you quote when OVMF's platform boot manager library, in OvmfPkg/Library/PlatformBootManagerLib, signals it. That's part of the BDS (Boot Device Selection) phase. Similarly, ArmVirtQemu signals AcpiPlatformDxe from "ArmVirtPkg/Library/PlatformBootManagerLib". However, the event we're hooking in this patch set is different, and it occurs later. It's called "Ready To Boot", and it is emitted / signaled by the UEFI boot manager when it is about to launch a boot option. See EFI_EVENT_GROUP_READY_TO_BOOT under EFI_BOOT_SERVICES.CreateEventEx() in the UEFI spec. Given that upstream OVMF and ArmVirt builds include / re-create a UEFI boot option for the built-in UEFI shell, there's always something that can be booted, even without disks / NICs. Thus, if you launch a diskless/NIC-less guest with such fw images, the event will be signaled (and the structure will be populated) no later than the built-in UEFI shell is launched. The qtest case should simply wait for that. > Do you have a QEMU companion patch for this series? I totally don't; I'm not going to write it. :) This patch set is to support the work of QEMU developers. And, clearly, I'm not going to push it until someone says, "yes, I've got a working QEMU series that interfaces with this". I'm fairly certain this series works as intended, because I tested it as follows: I booted a guest, waited for the firmware log to confirm that the callback was called (the log also indicated the correctly aligned address of the structure, and the RSDP1.0 / RSDP2.0 fields written to the structure), and then I used the "xp" QEMU monitor commands (via HMP) to print the guest RAM in the area, and to verify the GUID & the RSDP fields. Another possibility (for debugging the qtest work) is to dump the entire guest RAM with the "dump-guest-memory" monitor command (in ELF format), and to search the dump for the byte array in question (I think at least "mcview" and "vbindiff" can search binary files for byte sequences). Given the XOR trickery, you should have exactly one match, at a MB-aligned address, assuming you waited long enough before dumping. (The executable image of the DXE driver will not match.) Thanks Laszlo