Re: [PATCH V3 3/3] runqemu: Define OECORE_MACHINE_SYSROOT on setup_sysroot

[Patrick Ohly <patrick.ohly@intel.com>]

On Tue, 2015-07-14 at 20:07 +0000,
leonardo.sandoval.gonzalez@linux.intel.com wrote:
> From: Leonardo Sandoval <leonardo.sandoval.gonzalez@linux.intel.com>
> 
> At least the OVFM (UEFI Firmware for Qemu and KVM) recipe stores the BIOS
> under $OE_TMPDIR/sysroots/$MACHINE, now defined as OECORE_MACHINE_SYSROOT.
> The latter is used when searching BIOS, VGA BIOS and keymaps. As a example,
> to boot a OVFM BIOS, one can run the following command:
> 
> $ runqemu qemux86-64 core-image-minimal \
>     biosdir=usr/share/ovmf  \
>     biosfilename=bios.bin \
>     nographic
> 
> Note the bios* parameters: these two are needed to specify the subfolder
> (parent folder is OECORE_MACHINE_SYSROOT) and BIOS filename (without it,
> it picks a BIOS named bios-256k.bin).

While researching the nvram support question I came across the ovmf
whitepaper [1] showing how to use OVMF via "-drive
if=pflash,format=raw,file=fedora.flash" (where fedora.flash is a per-vm
copy of OVMF.fd = bios.bin in the sysroot).

I kept wondering why you were using "-bios bios.bin" instead of the
-drive method, and how that would affect nvram support. Then I found a
pretty clear statement by Laszlo Ersek, one of the OVMF co-maintainers,
saying [2] that -bios and the nvram support possible with it (storing in
an NvRam file in the EFI boot partition) are a kludge that should not be
used anymore.

So in other words, this particular patch needs further work. Perhaps add
an "ovmf" keyword (selecting the bios.bin as pflash drive), file name
handling (treat anything ending in .bin or .fd as pflash, supporting
more than one) and a OVMF env variable with a corresponding colon
separated list of pflash files?

I also wonder about the "bios.bin" name and the ".bin" suffix. I think
it would be better to stick with the upstream convention and just
install the file in the sysroot as OVMF.fd. This simplifies the file
name handling such that only .fd is special.

Note that the upstream discussion was about per-vm nvram storage. I
think in the context of runqemu it is okay to have a single file per
build configuration, because effectively we are creating a single
machine with one OS image. What's less nice is that the sysroot will get
modified when using bios.bin as pflash drive. Resetting the nvram needs
to be done with "bitbake -c clean ovmf && bitbake ovmf". Both is not
obvious.

Perhaps if runqemu picks up the file automatically from the sysroot (the
"ovmf" keyword usage), it should make a copy in tmp (on first run) and
then use that copy instead?

[1] http://www.linux-kvm.org/downloads/lersek/ovmf-whitepaper-c770f8c.txt
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=764918#47

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.