qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Igor Mammedov <imammedo@redhat.com>
To: Laszlo Ersek <lersek@redhat.com>
Cc: qemu-devel@nongnu.org, Gonglei <arei.gonglei@huawei.com>,
	"Shannon Zhao" <shannon.zhaosl@gmail.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	"Philippe Mathieu-Daudé" <philmd@redhat.com>,
	"Samuel Ortiz" <sameo@linux.intel.com>,
	"Andrew Jones" <drjones@redhat.com>
Subject: Re: [Qemu-devel] [PATCH 10/14] tests: acpi: ignore SMBIOS tests when UEFI firmware is used
Date: Wed, 16 Jan 2019 11:32:27 +0100	[thread overview]
Message-ID: <20190116113227.47ebdea2@redhat.com> (raw)
In-Reply-To: <15698cec-79eb-7a17-cf70-3a8fcb7962a6@redhat.com>

On Tue, 15 Jan 2019 21:31:54 +0100
Laszlo Ersek <lersek@redhat.com> wrote:

> On 01/15/19 16:41, Igor Mammedov wrote:
> > once FW provides a pointer to SMBIOS entry point like it does for
> > RSDP it should be possible to enable this one the same way.  
> 
> Good point, I didn't think of SMBIOS.
> 
> We have the following options:
> 
> (1) Use just one "test support" structure, and add more fields (such as
> the SMBIOS entry point) to it, beyond the RSDP1.0/RSDP2.0. For this, we
> should also introduce a "size" field to the table, so we don't have to
> extend the table between firmware and QEMU in lock-step.
> 
> (2) Use a different table (with a different GUID) for exposing the
> SMBIOS entry point.
> 
> On the firmware side, (1) would be more work now, but it would keep
> things simpler (and better separated) in the future. (2) would be more
> lazy ^W convenient now, but it would introduce more churn / possibly
> some code duplication in the future.
> 
> In QEMU, which one would you prefer?
I'd prefer #1 to minimize # of memory scans.
However with size (i.e. implicit versioning) and who know what else in
the future complexity grows up and dependency this approach causes
between firmware and QEMU (I dislike special build instead of reusing
shipped images).

So I've dug a little bit into the history why we've chosen including
structure into the firmware itself instead of writing EFI application
as part of QEMU that would provide the same test structure but won't
require special firmware build.
If I sum it up, it was issue with distros are shipping (if they do it at all)
only a version that matches distro's architecture and a need for cross
compiling EFI test app.

Could we revisit EFI app approach (I'd prefer it over firwmare hack if it's
possible)? We can try to avoid dependency on gnu-efi and cross compiling on
regular builds and ship along with efi app source code several prebuild app
binaries (boot disk images), that one would rebuild only when efi app
is changed, and it could be done manually (the same like special fw build
but contained withing QEMU). As for gnu-efi, is it possible to use striped
down gnu-efi stubs to drop external library dependency, something along of
lines https://github.com/tqh/efi-example ?


> Thanks,
> Laszlo
> 
> > 
> > Signed-off-by: Igor Mammedov <imammedo@redhat.com>
> > ---
> >  tests/bios-tables-test.c | 7 +++++--
> >  1 file changed, 5 insertions(+), 2 deletions(-)
> > 
> > diff --git a/tests/bios-tables-test.c b/tests/bios-tables-test.c
> > index d9efe59..a64d0c2 100644
> > --- a/tests/bios-tables-test.c
> > +++ b/tests/bios-tables-test.c
> > @@ -562,8 +562,11 @@ static void test_acpi_one(const char *params, test_data *data)
> >          }
> >      }
> >  
> > -    test_smbios_entry_point(data);
> > -    test_smbios_structs(data);
> > +    /* TODO: make SMBIOS tests work with UEFI firmware */
> > +    if (!use_uefi) {
> > +        test_smbios_entry_point(data);
> > +        test_smbios_structs(data);
> > +    }
> >  
> >      assert(!global_qtest);
> >      qtest_quit(data->qts);
> >   
> 
> 

  reply	other threads:[~2019-01-16 10:32 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-15 15:40 [Qemu-devel] [PATCH 00/14] tests: acpi: add UEFI (ARM) testing support Igor Mammedov
2019-01-15 15:40 ` [Qemu-devel] [PATCH 01/14] tests: acpi: add uefi_find_rsdp_addr() helper Igor Mammedov
2019-01-15 20:06   ` Laszlo Ersek
2019-01-16  9:48     ` Igor Mammedov
2019-01-15 15:40 ` [Qemu-devel] [PATCH 02/14] tests: acpi: make RSDT test routine handle XSDT Igor Mammedov
2019-01-16 16:47   ` Philippe Mathieu-Daudé
2019-01-15 15:40 ` [Qemu-devel] [PATCH 03/14] tests: acpi: rename acpi_parse_rsdp_table() into acpi_fetch_rsdp_table() Igor Mammedov
2019-01-16 16:48   ` Philippe Mathieu-Daudé
2019-01-15 15:40 ` [Qemu-devel] [PATCH 04/14] tests: acpi: make pointer to RSDP 64bit Igor Mammedov
2019-01-15 20:09   ` Laszlo Ersek
2019-01-16 16:51   ` Philippe Mathieu-Daudé
2019-01-15 15:40 ` [Qemu-devel] [PATCH 05/14] tests: acpi: fetch X_DSDT if pointer to DSDT is 0 Igor Mammedov
2019-01-17 14:02   ` Philippe Mathieu-Daudé
2019-01-17 15:02     ` Igor Mammedov
2019-01-15 15:40 ` [Qemu-devel] [PATCH 06/14] tests: acpi: add reference blobs arm/virt board testcase Igor Mammedov
2019-01-15 15:40 ` [Qemu-devel] [PATCH 07/14] tests: acpi: skip FACS table if board uses hw reduced ACPI profile Igor Mammedov
2019-01-16 16:58   ` Philippe Mathieu-Daudé
2019-01-15 15:41 ` [Qemu-devel] [PATCH 08/14] tests: acpi: introduce an abilty start tests with UEFI firmware Igor Mammedov
2019-01-15 20:18   ` Laszlo Ersek
2019-01-16 10:02     ` Igor Mammedov
2019-01-15 15:41 ` [Qemu-devel] [PATCH 09/14] tests: acpi: move boot_sector_init() into x86 tests branch Igor Mammedov
2019-01-16 16:59   ` Philippe Mathieu-Daudé
2019-01-15 15:41 ` [Qemu-devel] [PATCH 10/14] tests: acpi: ignore SMBIOS tests when UEFI firmware is used Igor Mammedov
2019-01-15 20:31   ` Laszlo Ersek
2019-01-16 10:32     ` Igor Mammedov [this message]
2019-01-16 11:07       ` Laszlo Ersek
2019-01-16 11:09         ` Laszlo Ersek
2019-01-16 12:20           ` Igor Mammedov
2019-01-16 16:17             ` Laszlo Ersek
2019-01-17 15:22               ` Igor Mammedov
2019-01-16 11:52         ` Gerd Hoffmann
2019-01-16 12:31           ` Igor Mammedov
2019-01-16 16:22             ` Laszlo Ersek
2019-01-17 15:11               ` Igor Mammedov
2019-01-18 23:28                 ` Laszlo Ersek
2019-01-16 15:25           ` Michael S. Tsirkin
2019-01-15 15:41 ` [Qemu-devel] [PATCH 12/14] tests: acpi: prepare AVMF firmware blobs to be used by bios-tables-test Igor Mammedov
2019-01-15 15:41 ` [Qemu-devel] [PATCH 13/14] tests: acpi: add simple arm/virt testcase Igor Mammedov
2019-01-15 15:41 ` [Qemu-devel] [PATCH 14/14] tests: acpi: refactor rebuild-expected-aml.sh to dump ACPI tables for a specified list of targets Igor Mammedov
2019-01-16 17:08   ` Philippe Mathieu-Daudé
2019-01-17 15:28     ` Igor Mammedov
     [not found] ` <1547566866-129386-12-git-send-email-imammedo@redhat.com>
2019-01-15 20:47   ` [Qemu-devel] [PATCH 11/14] tests: acpi: add AVMF firmware blobs Laszlo Ersek
2019-01-16 12:29     ` Igor Mammedov
2019-01-16 16:01       ` Michael S. Tsirkin
2019-01-17  8:53         ` Laszlo Ersek
2019-01-17  8:58           ` Laszlo Ersek
2019-01-17 10:22           ` Gerd Hoffmann
2019-01-17 12:54             ` Laszlo Ersek
2019-01-17 14:09               ` Gerd Hoffmann
2019-01-18 23:23                 ` Laszlo Ersek
2019-01-17 15:42               ` Igor Mammedov

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-all 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=20190116113227.47ebdea2@redhat.com \
    --to=imammedo@redhat.com \
    --cc=arei.gonglei@huawei.com \
    --cc=drjones@redhat.com \
    --cc=lersek@redhat.com \
    --cc=mst@redhat.com \
    --cc=philmd@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=sameo@linux.intel.com \
    --cc=shannon.zhaosl@gmail.com \
    /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;
as well as URLs for NNTP newsgroup(s).