qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC PATCH 0/3] acceptance tests: Test firmware checkin


From: Cleber Rosa
Subject: Re: [Qemu-devel] [RFC PATCH 0/3] acceptance tests: Test firmware checking debug console output
Date: Wed, 3 Oct 2018 11:20:03 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0


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
> 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]