public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Philippe Mathieu-Daudé" <philmd@redhat.com>
To: Laszlo Ersek <lersek@redhat.com>, edk2-devel@lists.01.org
Cc: Anthony Perard <anthony.perard@citrix.com>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	Drew Jones <drjones@redhat.com>,
	Igor Mammedov <imammedo@redhat.com>,
	Jordan Justen <jordan.l.justen@intel.com>,
	Julien Grall <julien.grall@linaro.org>
Subject: Re: [PATCH 1/4] OvmfPkg: introduce ACPI Test Support data structure and GUID
Date: Mon, 26 Nov 2018 22:43:20 +0100	[thread overview]
Message-ID: <8dcb0e57-cfde-8eea-938d-753320d0c031@redhat.com> (raw)
In-Reply-To: <20181125100152.25675-2-lersek@redhat.com>

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, but keep failing trying to test it with QEMU :/
I modified a bit tests/bios-tables-test.c to use the OVMF.fd build for
the Q35 machine tests, but still pass the "OnRootBridgesConnected: root
bridges have been connected, installing ACPI tables".

Do you have a QEMU companion patch for this series?

> 
> 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
>   }


  reply	other threads:[~2018-11-26 21:43 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-25 10:01 [PATCH 0/4] OvmfPkg, ArmVirtPkg: add ACPI Test Support Laszlo Ersek
2018-11-25 10:01 ` [PATCH 1/4] OvmfPkg: introduce ACPI Test Support data structure and GUID Laszlo Ersek
2018-11-26 21:43   ` Philippe Mathieu-Daudé [this message]
2018-11-27 11:23     ` Laszlo Ersek
2018-12-03 17:09   ` Igor Mammedov
2018-12-04 17:09     ` Laszlo Ersek
2018-12-26 20:24       ` Laszlo Ersek
2018-12-27  5:11         ` Igor Mammedov
2018-11-25 10:01 ` [PATCH 2/4] OvmfPkg/AcpiPlatformDxe: list missing lib classes for QemuFwCfgAcpiPlatformDxe Laszlo Ersek
2018-11-25 10:01 ` [PATCH 3/4] OvmfPkg/AcpiPlatformDxe: add [Un]RegisterAcpiTestSupport() skeletons Laszlo Ersek
2018-11-25 10:01 ` [PATCH 4/4] OvmfPkg/AcpiPlatformDxe: fill in ACPI_TEST_SUPPORT at first Ready-To-Boot Laszlo Ersek
2018-11-26 17:21 ` [PATCH 0/4] OvmfPkg, ArmVirtPkg: add ACPI Test Support Ard Biesheuvel
2018-11-27 11:02   ` Laszlo Ersek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8dcb0e57-cfde-8eea-938d-753320d0c031@redhat.com \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox