[Qemu-devel] [RFC PATCH 1/3] acceptance tests: Add SeaBIOS boot and debug console checking test

[Qemu-devel] [RFC PATCH 1/3] acceptance tests: Add SeaBIOS boot and debug console checking test

[Cleber Rosa]

On 9/27/18 8:30 PM, Philippe Mathieu-Daudé wrote:
> This test boots SeaBIOS and check the debug console (I/O port on the ISA bus)
> reports enough information on the initialized devices.
> 
> Example:
> 
>     $ avocado --show=debugcon run tests/acceptance/boot_firmware.py
> 
> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
> ---
> - can we avoid the time.time() 2nd timeout check?
> 

The problem here is that the "draining" of the console is done
synchronously and at the same time the "if 'No bootable device.' in msg"
check is performed.

If we split those, it could become a simple function that can be given
to wait_for():

https://avocado-framework.readthedocs.io/en/65.0/api/utils/avocado.utils.html#avocado.utils.wait.wait_for

Something like:

   if not wait_for(check_bootable(), 5):
       self.fail("Reason")

Greatly simplifying the code.

> - can we avoid tempfile.mkdtemp() + shutil.rmtree() with Python2?
>   (using context manager)

Yep, workdir is your friend.  More on that later.

> ---
>  tests/acceptance/boot_firmware.py | 72 +++++++++++++++++++++++++++++++
>  1 file changed, 72 insertions(+)
>  create mode 100644 tests/acceptance/boot_firmware.py
> 
> diff --git a/tests/acceptance/boot_firmware.py b/tests/acceptance/boot_firmware.py
> new file mode 100644
> index 0000000000..a41e04936d
> --- /dev/null
> +++ b/tests/acceptance/boot_firmware.py
> @@ -0,0 +1,72 @@
> +# coding=utf-8
> +#
> +# Functional test that boots SeaBIOS and checks the console
> +#
> +# Copyright (c) 2018 Red Hat, Inc.
> +#
> +# Author:
> +#  Philippe Mathieu-Daudé <philmd@redhat.com>
> +#
> +# SPDX-License-Identifier: GPL-2.0-or-later
> +
> +import os
> +import time
> +import shutil
> +import logging
> +import tempfile
> +
> +from avocado_qemu import Test
> +
> +
> +class BootFirmwareX86(Test):
> +    """
> +    Boots a firmware on a default PC machine and checks the debug console is
> +    operational
> +
> +    :avocado: enable
> +    :avocado: tags=x86_64,quick

Eventually, we'll need to have a predictable definition to, at least,
some of the tags.  I mean, I agree this *should* be a quick by test
(considering it's a functional test), but eventually we may want to set
some ranges for what we consider "quick", "slow" or "I'm gonna take my
time, don't wait on me". :)

> +    """
> +
> +    timeout = 15
> +
> +    def test_seabios(self):
> +        tmpdirname = tempfile.mkdtemp()

Every Avocado test has a "workdir" that can be used for temporary
content.  That property points to a directory will be discarded after
the test has finished.  Documentation is here:

https://avocado-framework.readthedocs.io/en/65.0/api/test/avocado.html#avocado.Test.workdir

> +        debugcon_path = os.path.join(tmpdirname, 'debugconsole.log')
> +        serial_logger = logging.getLogger('serial')
> +        debugcon_logger = logging.getLogger('debugcon')
> +
> +        self.vm.set_machine('pc')
> +        self.vm.set_console()
> +        self.vm.add_args('-nographic',
> +                         '-net', 'none',
> +                         '-global', 'isa-debugcon.iobase=0x402',
> +                         '-debugcon', 'file:%s' % debugcon_path)
> +        self.vm.launch()
> +        console = self.vm.console_socket.makefile()
> +
> +        # serial console checks
> +        timeout = time.time() + 5
> +        while True:
> +            msg = console.readline()
> +            if not '\x1b' in msg: # ignore ANSI sequences
> +                serial_logger.debug(msg.strip())
> +            if 'No bootable device.' in msg:
> +                break
> +            if time.time() > timeout:
> +                self.fail('SeaBIOS failed to boot?')

It looks like tests such as this could benefit from having an async
method of draining a given file (descriptor or object) and putting that
into a log.  Then, the boilerplate code of reading from a file and
writing to a log could be avoided.

In theory, Avocado has such a tool:

https://avocado-framework.readthedocs.io/en/65.0/api/utils/avocado.utils.html#avocado.utils.process.FDDrainer

But it needs some TLC when it comes to being used on a test to really
remove boilerplate code. For instance, instead of having to do:

    debugcon_path = os.path.join(self.workdir, 'debug_console.log')
    debugcon_logger = logging.getLogger('debugcon')
    ...
    lines = open(debugcon_path).readlines()
    for msg in lines:
        debugcon_logger.debug(msg.strip())

One should be able to do:

   # debug_console.log is created with the content of debugcon_path
   self.log_file(debugcon_path, "debug_console")

> +
> +        # debug console checks
> +        expected = [
> +            'Running on QEMU (i440fx)',
> +            'Turning on vga text mode console',
> +            'Found 1 lpt ports',
> +            'Found 1 serial ports',
> +            'PS2 keyboard initialized',
> +        ]
> +        lines = open(debugcon_path).readlines()
> +        for msg in lines:
> +            debugcon_logger.debug(msg.strip())
> +        for line in expected:
> +            if line + '\n' not in lines:
> +                self.fail('missing: %s' % line)

A slightly more Pythonic version would be:

   with open(debugcon_path) as debugcon:
      content = debugcon.readlines()
      for exp in expected:
          self.assertIn(expected, content)

> +        shutil.rmtree(tmpdirname, ignore_errors=True)
> 

And by using workdir you don't need this manual cleanup.

Re: [Qemu-devel] [RFC PATCH 1/3] acceptance tests: Add SeaBIOS boot and debug console checking test

[Philippe Mathieu-Daudé]

On 10/3/18 1:26 AM, Cleber Rosa wrote:
[...]
>> +    :avocado: enable
>> +    :avocado: tags=x86_64,quick
> 
> Eventually, we'll need to have a predictable definition to, at least,
> some of the tags.  I mean, I agree this *should* be a quick by test
> (considering it's a functional test), but eventually we may want to set
> some ranges for what we consider "quick", "slow" or "I'm gonna take my
> time, don't wait on me". :)

Maybe we can set a timeout tag and let the user choose how long he is
willing to wait:

   :avocado: max_time=20s

>> +    """
>> +
>> +    timeout = 15
>> +
>> +    def test_seabios(self):
[...]

Re: [Qemu-devel] [RFC PATCH 2/3] acceptance tests: Add EDK2 OVMF boot and debug console checking test

[Cleber Rosa]

On 9/27/18 8:30 PM, Philippe Mathieu-Daudé wrote:
> This test boots OVMF and check the debug console (I/O port on the ISA bus)
> report enough information on the initialized devices.
> 
> Example:
> 
>     $ avocado --show=QMP,serial run tests/acceptance/boot_firmware.py
> 
> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
> ---
> - how to refactor common code from test_seabios() (previous patch)?
> ---
>  tests/acceptance/boot_firmware.py | 52 +++++++++++++++++++++++++++++++
>  1 file changed, 52 insertions(+)
> 
> diff --git a/tests/acceptance/boot_firmware.py b/tests/acceptance/boot_firmware.py
> index a41e04936d..05f6728212 100644
> --- a/tests/acceptance/boot_firmware.py
> +++ b/tests/acceptance/boot_firmware.py
> @@ -70,3 +70,55 @@ class BootFirmwareX86(Test):
>              if line + '\n' not in lines:
>                  self.fail('missing: %s' % line)
>          shutil.rmtree(tmpdirname, ignore_errors=True)

Almost every comment on the previous patch applies here of course.
Because of that, it may make sense to generalize some of these patterns
into utility methods and/or, move some common setup code into a setUp()
method.

> +
> +    def test_ovmf(self):
> +        tmpdirname = tempfile.mkdtemp()
> +        debugcon_path = os.path.join(tmpdirname, 'debugconsole.log')
> +        serial_logger = logging.getLogger('serial')
> +        debugcon_logger = logging.getLogger('debugcon')
> +
> +        self.vm.set_machine('pc')
> +        self.vm.set_console()
> +        self.vm.add_args('-nographic',
> +                         '-net', 'none',
> +                         '-global', 'isa-debugcon.iobase=0x402',
> +                         '-debugcon', 'file:%s' % debugcon_path,

For instance, the setting up of the machine type, console and these
common arguments seem to be good candidates to be moved to a common
setUp() method.

> +                         '--bios', '/usr/share/OVMF/OVMF_CODE.fd')

This would be the difference between the arguments of this and the
seabios test, so it could be given by itself here (with the rest on
setUp()).

> +        self.vm.launch()
> +        console = self.vm.console_socket.makefile()
> +
> +        # serial console checks
> +        timeout = time.time() + 15
> +        while True:
> +            msg = console.readline()
> +            if not '\x1b' in msg: # ignore ANSI sequences
> +                serial_logger.debug(msg.strip())
> +            if 'EDK II' in msg:
> +                break
> +            if time.time() > timeout:
> +                self.fail('OVMF failed to boot?')
> +

This seems to be a code block that could become something like:

   def check_boot(self, pattern, timeout):
       ...
       self.fail("Failed to boot")

IMO, a generic fail reason is enough, given that it's associated with
the "test_ovmf".

> +        # debug console checks
> +        expected = [
> +            'SEC: Normal boot',
> +            'S3 support was detected on QEMU',
> +            'Platform PEI Firmware Volume Initialization',
> +            'DXE IPL Entry',
> +            'Installing FVB for EMU Variable support',
> +            'DetectSmbiosVersion: SMBIOS version from QEMU: 0x0208',
> +            'SmbiosCreateTable: Initialize 32-bit entry point structure',
> +            'PlatformBootManagerBeforeConsole',
> +            'OnRootBridgesConnected: root bridges have been connected, '
> +                'installing ACPI tables',
> +            'Found LPC Bridge device',
> +            'PlatformBootManagerAfterConsole',
> +            'EfiBootManagerConnectAll',
> +            '[Bds]Booting EFI Internal Shell',
> +        ]
> +        lines = open(debugcon_path).readlines()
> +        for msg in lines:
> +            debugcon_logger.debug(msg.strip())
> +        for line in expected:
> +            if line + '\r\n' not in lines:
> +                self.fail('missing: %s' % line)
> +        shutil.rmtree(tmpdirname, ignore_errors=True)
> 

And this could also become something like:

   def check_console(self, patterns):
      with open(self.test_logs["debugcon"]) as debugcon:
      content = debugcon.readlines()
      for expected in patterns:
          self.assertIn(expected, content)

Assuming "self.test_logs" is a byproduct of the "self.log_file()"
suggestion for the new feature given previously.

Re: [Qemu-devel] [RFC PATCH 3/3] acceptance tests: Add EDK2 AAVMF boot and console checking test

[Cleber Rosa]

On 9/27/18 8:30 PM, Philippe Mathieu-Daudé wrote:
> This test boots EDK2 AAVMF and check the debug console (PL011) reports enough
> information on the initialized devices.
> 
> Example:
> 
>     $ avocado --show=console run tests/acceptance/boot_firmware.py --cit-parameter-file aarch64.cit
> 
> having aarch64.cit:
> 
> [parameters]
> qemu_bin: aarch64-softmmu/qemu-system-aarch64
> 
> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
> ---
> - requires (even for single parameter):
>   $ pip install avocado-framework-plugin-varianter-cit
> 

Avocado 65.0 now features a core parameter passing option (one that
doesn't depend on the varianter).  Command line option is documented as:

  -p NAME_VALUE, --test-parameter NAME_VALUE
                Parameter name and value to pass to all tests. This is
                only applicable when not using a varianter plugin.
                This option format must be given in the NAME=VALUE
                format, and may be given any number of times, or per
                parameter.

> - use gzip kludge (avocado only support tarballs)
> 

I'll finish the work to get that into the avocado.utils.archive module.

> - can not set $arch param since pick_default_qemu_bin() forces to host os.uname()[4]

This is definitely a common requirement, and something to be addressed
ASAP.  I have a patch on my tree (pretty simple change) that I'll be
sending shortly.

> ---
>  tests/acceptance/boot_firmware.py | 43 +++++++++++++++++++++++++++++++
>  1 file changed, 43 insertions(+)
> 
> diff --git a/tests/acceptance/boot_firmware.py b/tests/acceptance/boot_firmware.py
> index 05f6728212..4f5554c0ad 100644
> --- a/tests/acceptance/boot_firmware.py
> +++ b/tests/acceptance/boot_firmware.py
> @@ -10,6 +10,7 @@
>  # SPDX-License-Identifier: GPL-2.0-or-later
>  
>  import os
> +import gzip
>  import time
>  import shutil
>  import logging
> @@ -122,3 +123,45 @@ class BootFirmwareX86(Test):
>              if line + '\r\n' not in lines:
>                  self.fail('missing: %s' % line)
>          shutil.rmtree(tmpdirname, ignore_errors=True)
> +
> +
> +class BootFirmwareAarch64(Test):
> +    """
> +    Boots the EDK2 firmware on a default virt machine and checks the console is
> +    operational
> +
> +    :avocado: enable
> +    :avocado: tags=arch:aarch64

Yay, I like where you're going here.  This matches what I said before
about having some standardization on the tags.

On a related topic, sometimes tests can be written in an abstract way
that parameters only will allow the same test to be reused in different
arches, but, sometimes we may need to explicit include/exclude some
tests on some executions - then tags could be a foundation for that.

> +    :avocado: tags=aarch64,quick
> +    """
> +
> +    timeout = 15
> +
> +    def test_aavmf(self):
> +        tmpdirname = tempfile.mkdtemp()
> +        image_url = ('http://snapshots.linaro.org/components/kernel/'
> +                    'leg-virt-tianocore-edk2-upstream/latest/'
> +                    'QEMU-AARCH64/DEBUG_GCC5/QEMU_EFI.img.gz')
> +        image_path_gz = self.fetch_asset(image_url)
> +        image_path = os.path.join(tmpdirname, 'flash.img')
> +        with gzip.open(image_path_gz) as gz, open(image_path, 'wb') as img:
> +            shutil.copyfileobj(gz, img)
> +
> +        self.vm.set_machine('virt')
> +        self.vm.set_console()
> +        self.vm.add_args('-nographic',
> +                         '-cpu', 'cortex-a57',
> +                         '-m', '1G',

Is there a reason for defining this exact amount of memory?  My question
has to do with the idea of setting some "sane" hardware defaults at the
base test level (to avoid boiler plate code).

> +                         '-pflash', image_path)
> +        self.vm.launch()
> +        console = self.vm.console_socket.makefile()
> +        serial_logger = logging.getLogger('serial')
> +
> +        # serial console checks
> +        while True:
> +            msg = console.readline()
> +            if not '\x1b' in msg: # ignore ANSI sequences
> +                serial_logger.debug(msg.strip())
> +            if 'Start PXE over IPv4InstallProtocolInterface:' in msg:
> +                break
> +        shutil.rmtree(tmpdirname, ignore_errors=True)
> 

Again, seems like a candidate for the ideas presented on the previous
patches.

Thanks for sending those, lots of interesting opportunities.

- Cleber.

Re: [Qemu-devel] [RFC PATCH 0/3] acceptance tests: Test firmware checking debug console output

[Cleber Rosa]

On 9/28/18 6:51 AM, Laszlo Ersek wrote:
> Hi Phil,
> 
> (+Daniel, +Kashyap)
> 
> On 09/28/18 02:30, Philippe Mathieu-Daudé wrote:
>> Hi,
>>
>> This RFC series add simple acceptance tests which boot SeaBIOS and
>> EDK2 on Q35 and virt/aarch64.
>>
>> It is more of a proof of concept (to motivate the Avocado team ;) ).
>>
>> Regards,
>>
>> Phil.
>>
>> Philippe Mathieu-Daudé (3):
>>   acceptance tests: Add SeaBIOS boot and debug console checking test
>>   acceptance tests: Add EDK2 OVMF boot and debug console checking test
>>   acceptance tests: Add EDK2 AAVMF boot and console checking test
>>
>>  tests/acceptance/boot_firmware.py | 167 ++++++++++++++++++++++++++++++
>>  1 file changed, 167 insertions(+)
>>  create mode 100644 tests/acceptance/boot_firmware.py
>>
> 
> I'm not experienced with Avocado, so I'm basically reading the patches
> as a "story". My comments are made at that level too. :)
> 
> * In the blurb, you say "Q35". But the first two patches have
> 
>   vm.set_machine('pc')
> 
> * Please don't call the edk2 ArmVirtQemu platform AAVMF in upstream
>   patches :) Call it ArmVirtQemu pls.
> 
> * Finding the right way to launch  OVMF and/or ArmVirtQemu firmware
>   images is complicated. (The right way is definitely not "-bios"!)
> 
>   The general idea is that you need three files (and two pflash chips);
>   (a) a firmware executable mapped read-only, and (b) a variable store
>   file, mapped read-write, that was first copied from (c) a read-only
>   variable store *template* that is never itself mapped. And, this is
>   not the whole story.
> 
>   Figuring out the options is complicated enough (for management tools
>   as well) that Daniel made us define a metadata schema for describing
>   firmware packages. Please see:
> 
>   docs/interop/firmware.json
> 
>   I'm not necessarily suggesting that Avocado be able to parse the
>   firmware descriptor metafiles that conform to this schema. I'm just
>   pointing out that the QEMU command line will depend on the exact build
>   of the firmware image under test. The pathname
>   "/usr/share/OVMF/OVMF_CODE.fd" and the URL
>   "https://snapshots.linaro.org/.../QEMU_EFI.img.gz" don't give us
>   enough information.
> 
>   Therefore, if we want to keep the test case simple (= hard-wire the
>   command lines), then we'll have to refer to OVMF and ArmVirtQemu
>   images with precisely known build configs.
> 
> * Looking for debug console messages as "vital signs" is brittle. For
>   example, the line "DetectSmbiosVersion: SMBIOS version from QEMU:
>   0x0208" will change if QEMU changes the SMBIOS version number in the
>   SMBIOS anchor that it generates. It's likely better to make the
>   firmware "do" something.
> 
>   The simplest I can imagine is: prepare a virtual disk with a
>   "startup.nsh" UEFI shell script on it. The script can print a known
>   fixed string, and then power down the VM. (See the UEFI Shell
>   Specification for commands; <http://uefi.org/specifications>.)
> 
>   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.

- Cleber.

Re: [Qemu-devel] [RFC PATCH 0/3] acceptance tests: Test firmware checking debug console output

[Laszlo Ersek]

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

Re: [Qemu-devel] [RFC PATCH 0/3] acceptance tests: Test firmware checking debug console output

[Cleber Rosa]

On 10/3/18 3:13 AM, Laszlo Ersek wrote:
> 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),
> 

Is FAT12 an option here?  The reason I ask is that there may be code
FAT12 capable code ready to be incorporated:

https://github.com/clalancette/pyfat

> - 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).
> 

ISO with ElTorito should be easy to do with what we have right now, I'll
check what "-efi-boot" and "-no-emul-boot" do to make sure we can mimic it.

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

Yes, this sounds like the interface we need here.

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

Avocado has a subproject called aexpect:

https://github.com/avocado-framework/aexpect

It can be used to communicate with (among others) serial consoles.  This
is how it's done on Avocado-VT:

https://github.com/avocado-framework/avocado-vt/blob/master/virttest/qemu_vm.py#L2376

Thanks!
- Cleber.

> Thanks!
> Laszlo
> 

Re: [Qemu-devel] [RFC PATCH 0/3] acceptance tests: Test firmware checking debug console output

[Laszlo Ersek]

On 10/03/18 17:20, Cleber Rosa wrote:
> On 10/3/18 3:13 AM, Laszlo Ersek wrote:
>> 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),
>>
> 
> Is FAT12 an option here?  The reason I ask is that there may be code
> FAT12 capable code ready to be incorporated:
> 
> https://github.com/clalancette/pyfat

Theoretically, I should answer "yes". For two reasons:

(1) In "13.3 File System Format", the UEFI-2.7 spec writes,

"[...] EFI encompasses the use of FAT32 for a system partition, and
FAT12 or FAT16 for removable media. [...]"

(2) When invoking mkdosfs without the "-F" option, mkdosfs chooses the
smallest FAT filesystem variant that can accommodate the requested size.
We successfully format UEFI-readable ISO images that don't exceed e.g.
3MB in final size. This implies (and I have now actually checked, with
"dosfsck -v") that their embedded ElTorito image is FAT12. edk2 has no
trouble reading that.


However... the maximum volume size for FAT12 appears to be 32 MB,
according to wikipedia:

  https://en.wikipedia.org/wiki/File_Allocation_Table#FAT12

It doesn't look good for the long term. For example, I can imagine a
test case where you place a kernel executable (containing a UEFI stub)
and an initial ramdisk on the UEFI-readable ISO. Using the RHEL-7.5
kernel and the matching initrd from my laptop as an example: that's
already 6.2MB + 25MB.

So, technically, FAT12 should be fine; in practice, it could prove limiting.

[...]

Thanks!
Laszlo

Re: [Qemu-devel] [RFC PATCH 0/3] acceptance tests: Test firmware checking debug console output

[Cleber Rosa]

On 10/3/18 11:59 AM, Laszlo Ersek wrote:
> On 10/03/18 17:20, Cleber Rosa wrote:
>> On 10/3/18 3:13 AM, Laszlo Ersek wrote:
>>> 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),
>>>
>>
>> Is FAT12 an option here?  The reason I ask is that there may be code
>> FAT12 capable code ready to be incorporated:
>>
>> https://github.com/clalancette/pyfat
> 
> Theoretically, I should answer "yes". For two reasons:
> 
> (1) In "13.3 File System Format", the UEFI-2.7 spec writes,
> 
> "[...] EFI encompasses the use of FAT32 for a system partition, and
> FAT12 or FAT16 for removable media. [...]"
> 
> (2) When invoking mkdosfs without the "-F" option, mkdosfs chooses the
> smallest FAT filesystem variant that can accommodate the requested size.
> We successfully format UEFI-readable ISO images that don't exceed e.g.
> 3MB in final size. This implies (and I have now actually checked, with
> "dosfsck -v") that their embedded ElTorito image is FAT12. edk2 has no
> trouble reading that.
> 
> 
> However... the maximum volume size for FAT12 appears to be 32 MB,
> according to wikipedia:
> 
>   https://en.wikipedia.org/wiki/File_Allocation_Table#FAT12
> 
> It doesn't look good for the long term. For example, I can imagine a
> test case where you place a kernel executable (containing a UEFI stub)
> and an initial ramdisk on the UEFI-readable ISO. Using the RHEL-7.5
> kernel and the matching initrd from my laptop as an example: that's
> already 6.2MB + 25MB.
> 
> So, technically, FAT12 should be fine; in practice, it could prove limiting.
> 

Nice, thanks for the detailed info.  I think it's safe to start with
that, and improve the original project with FAT16/32 support.

Regards,
- Cleber.

> [...]
> 
> Thanks!
> Laszlo
> 

-- 
Cleber Rosa
[ Sr Software Engineer - Virtualization Team - Red Hat ]
[ Avocado Test Framework - avocado-framework.github.io ]
[  7ABB 96EB 8B46 B94D 5E0F  E9BB 657E 8D33 A5F2 09F3  ]