qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Laszlo Ersek <lersek@redhat.com>
To: "Cleber Rosa" <crosa@redhat.com>,
	"Philippe Mathieu-Daudé" <philmd@redhat.com>
Cc: "Eduardo Habkost" <ehabkost@redhat.com>,
	"Ard Biesheuvel" <ard.biesheuvel@linaro.org>,
	qemu-devel@nongnu.org, "Gerd Hoffmann" <kraxel@redhat.com>,
	"Caio Carrara" <ccarrara@redhat.com>,
	"Marc-André Lureau" <marcandre.lureau@redhat.com>,
	"Alex Bennée" <alex.bennee@linaro.org>,
	"Kashyap Chamarthy" <kchamart@redhat.com>
Subject: Re: [Qemu-devel] [RFC PATCH 0/3] acceptance tests: Test firmware checking debug console output
Date: Wed, 3 Oct 2018 09:13:36 +0200	[thread overview]
Message-ID: <a259468f-d11c-ea18-1708-a349b6014e71@redhat.com> (raw)
In-Reply-To: <3a670f0b-069e-5713-da7a-dea46959ff8d@redhat.com>

On 10/03/18 02:23, Cleber Rosa wrote:
> On 9/28/18 6:51 AM, Laszlo Ersek wrote:

>>   I'm not sure if Avocado provides disk image preparation utilities, but
>>   perhaps (a) we could use the vvfat driver (*shudder*) or (b) we could
>>   preformat a small image, and track it as a binary file in git.
>>
> 
> So far we've added support for generating ISO images (with pure Python).
> I'm not sure if that's useful here.  We can think about trying to add
> the same thing for vvfat.

The ability to generate ISO images (natively at that!) seems useful.
UEFI-readable ISO images need an extension on top: the ISO9660
filesystem has to get the ElTorito extension, and the ElTorito boot
image should be a FAT filesystem. Under UEFI, what's visible isn't the
ISO9660 filesystem itself, but the contents of the embedded ElTorito
boot image.

In terms of shell utilities, this usually involves:

- creating and populating the FAT filesystem image (with guestfish, or
  with mkdosfs+mtools),

- invoking genisoimage with "-efi-boot fat.img -no-emul-boot -- fat.img"
  (basically, place the FAT image into the ISO9660 filesystem like any
  other file, but pass additional options so that genisoimage know it's
  meant as the ElTorito boot image for UEFI).

If you can add this feature generically, such as:
- input: a hierarchy of files,
- output: a temporary ISO image file,

then IMO it would help with UEFI testing. Any given test case could then
generate a "startup.nsh" UEFI shell script, invoking UEFI shell
builtins, and possibly custom UEFI applications (also to be placed in
the ISO image). This could cover a good amount of batch scenarios (where
no interaction is needed).

Regarding interaction with the UEFI shell over serial, the
<https://github.com/puiterwijk/qemu-ovmf-secureboot> project for example
has successfully used "subprocess.Popen()". But, I guess I only want to
highlight the idea here ("talk to the UEFI shell via serial"), not the
exact implementation. I assume Avocado already has polished,
"expect"-like tools, for talking to the guest over the serial port.

Thanks!
Laszlo

  reply	other threads:[~2018-10-03  7:13 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20180928003058.12786-1-philmd@redhat.com>
     [not found] ` <20180928003058.12786-2-philmd@redhat.com>
2018-10-02 23:26   ` [Qemu-devel] [RFC PATCH 1/3] acceptance tests: Add SeaBIOS boot and debug console checking test Cleber Rosa
2018-10-03  0:00     ` Philippe Mathieu-Daudé
     [not found] ` <20180928003058.12786-3-philmd@redhat.com>
2018-10-03  0:08   ` [Qemu-devel] [RFC PATCH 2/3] acceptance tests: Add EDK2 OVMF " Cleber Rosa
     [not found] ` <20180928003058.12786-4-philmd@redhat.com>
2018-10-03  0:20   ` [Qemu-devel] [RFC PATCH 3/3] acceptance tests: Add EDK2 AAVMF boot and " Cleber Rosa
     [not found] ` <61123eb6-4263-4847-cb43-8160c99adb45@redhat.com>
2018-10-03  0:23   ` [Qemu-devel] [RFC PATCH 0/3] acceptance tests: Test firmware checking debug console output Cleber Rosa
2018-10-03  7:13     ` Laszlo Ersek [this message]
2018-10-03 15:20       ` Cleber Rosa
2018-10-03 15:59         ` Laszlo Ersek
2018-10-03 16:13           ` Cleber Rosa

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=a259468f-d11c-ea18-1708-a349b6014e71@redhat.com \
    --to=lersek@redhat.com \
    --cc=alex.bennee@linaro.org \
    --cc=ard.biesheuvel@linaro.org \
    --cc=ccarrara@redhat.com \
    --cc=crosa@redhat.com \
    --cc=ehabkost@redhat.com \
    --cc=kchamart@redhat.com \
    --cc=kraxel@redhat.com \
    --cc=marcandre.lureau@redhat.com \
    --cc=philmd@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /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).