Re: [PATCH 1/4] OvmfPkg: introduce ACPI Test Support data structure and GUID

[Laszlo Ersek <lersek@redhat.com>]

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