mirrors/qemu
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
69,482 Commits 50 Branches 394 Tags 404 MiB
7ac283e963
Commit Graph

5 Commits

Author SHA1 Message Date
Laszlo Ersek
b097ba371a tests/uefi-test-tools: report the SMBIOS entry point structures 
On UEFI systems, the SMBIOS entry point (a.k.a. anchor) structures are
found similarly to the ACPI RSD PTR table(s): by scanning the
ConfigurationTable array in the EFI system table for well-known GUIDs.

Locate the SMBIOS 2.1 (32-bit) and 3.0 (64-bit) anchors in the
BiosTablesTest UEFI application, and report the addresses in new fields
appended to the BIOS_TABLES_TEST structure.

Cc: "Philippe Mathieu-Daudé" <philmd@redhat.com>
Cc: Igor Mammedov <imammedo@redhat.com>
Launchpad: https://bugs.launchpad.net/qemu/+bug/1821884
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Tested-by: Igor Mammedov <imammedo@redhat.com>
 2019-05-03 10:52:20 +02:00
Laszlo Ersek
174404af92 tests/uefi-test-tools/build.sh: work around TianoCore#1607 
The edk2-stabe201903 release introduced Python3 support to edk2's
BaseTools; however the Python3 enablement breaks in a corner case (which
is nevertheless supported by the edk2 community), namely the in-module
parallelization that we utilize.

This is tracked under
<https://bugzilla.tianocore.org/show_bug.cgi?id=1607>. For now, work
around the issue (in advance) by forcing Python2. (The workaround is a
no-op before we move to edk2-stabe201903 in the roms/edk2 submodule.)

Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Tested-by: Igor Mammedov <imammedo@redhat.com>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
 2019-04-17 15:38:35 +02:00
Laszlo Ersek
65a109ab4b roms: lift "edk2-funcs.sh" from "tests/uefi-test-tools/build.sh" 
Extract the dense logic for architecture and toolchain massaging from
"tests/uefi-test-tools/build.sh", to a set of small functions. We'll reuse
these functions for building full platform firmware images.

Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Tested-by: Igor Mammedov <imammedo@redhat.com>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
 2019-04-17 15:38:35 +02:00
Laszlo Ersek
77db55fc81 tests/uefi-test-tools: add build scripts 
Introduce the following build scripts under "tests/uefi-test-tools":

* "build.sh" builds a single module (a UEFI application) from
  UefiTestToolsPkg, for a single QEMU emulation target.

  "build.sh" relies on cross-compilers when the emulation target and the
  build host architecture don't match. The cross-compiler prefix is
  computed according to a fixed, Linux-specific pattern. No attempt is
  made to copy or reimplement the GNU Make magic from "qemu/roms/Makefile"
  for cross-compiler prefix determination. The reason is that the build
  host OSes that are officially supported by edk2, and those that are
  supported by QEMU, intersect only in Linux. (Note that the UNIXGCC
  toolchain is being removed from edk2,
  <https://bugzilla.tianocore.org/show_bug.cgi?id=1377>.)

* "Makefile" currently builds the "UefiTestToolsPkg/BiosTablesTest"
  application, for arm, aarch64, i386, and x86_64, with the help of
  "build.sh".

  "Makefile" turns each resultant UEFI executable into a UEFI-bootable,
  qcow2-compressed ISO image. The ISO images are output as
  "tests/data/uefi-boot-images/bios-tables-test.<TARGET>.iso.qcow2".

  Each ISO image should be passed to QEMU as follows:

    -drive id=boot-cd,if=none,readonly,format=qcow2,file=$ISO \
    -device virtio-scsi-pci,id=scsi0 \
    -device scsi-cd,drive=boot-cd,bus=scsi0.0,bootindex=0 \

  "Makefile" assumes that "mkdosfs", "mtools", and "genisoimage" are
  present.

Cc: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Igor Mammedov <imammedo@redhat.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Cc: Shannon Zhao <shannon.zhaosl@gmail.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-Id: <20190204160325.4914-5-lersek@redhat.com>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
 2019-02-21 12:28:41 -05:00
Laszlo Ersek
09a274d82f tests: introduce "uefi-test-tools" with the BiosTablesTest UEFI app 
The "bios-tables-test" program in QEMU's test suite locates the RSD PTR
ACPI table in guest RAM, and (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. The ACPI
spec defines distinct methods for OSPM to locate the RSD PTR on
traditional BIOS vs. UEFI platforms, and the UEFI method is more difficult
to implement from the hypervisor side with just raw guest memory access.

Add a UEFI application (to be booted in the UEFI guest) that populates a
small, MB-aligned structure in guest RAM. The structure begins with a
signature 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.

The GUID that the hypervisor should search for is

  AB87A6B1-2034-BDA0-71BD-375007757785

Expressed as a byte array:

 {
   0xb1, 0xa6, 0x87, 0xab,
   0x34, 0x20,
   0xa0, 0xbd,
   0x71, 0xbd, 0x37, 0x50, 0x07, 0x75, 0x77, 0x85
 }

Note that in the patch, we define "gBiosTablesTestGuid" with all bits
inverted. This is a simple method to prevent the UEFI binary, which
incorporates "gBiosTablesTestGuid", from matching the actual GUID in guest
RAM.

The UEFI application is written against the edk2 framework, which was
introduced earlier as a git submodule. The next patch will provide build
scripts for maintainers.

The source code follows the edk2 coding style, and is licensed under the
2-clause BSDL (in case someone would like to include UefiTestToolsPkg
content in a different edk2 platform).

The "UefiTestToolsPkg.dsc" platform description file resolves the used
edk2 library classes to instances (= library implementations) such that
the UEFI binaries inherit no platform dependencies. They are expected to
run on any system that conforms to the UEFI-2.3.1 spec (which was released
in 2012). The arch-specific build options are carried over from edk2's
ArmVirtPkg and OvmfPkg platforms.

Cc: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Igor Mammedov <imammedo@redhat.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Cc: Shannon Zhao <shannon.zhaosl@gmail.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20190204160325.4914-4-lersek@redhat.com>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
 2019-02-21 12:28:41 -05:00