Re: OVMF.fd and placement of EfiBootServicesData

[spam collector <spamcollector@cableone.net>]

----- Original Message -----
> From: "Laszlo Ersek" <lersek@redhat.com>
> To: "spam collector" <spamcollector@cableone.net>
> Cc: edk2-devel@ml01.01.org
> Sent: Tuesday, October 4, 2016 10:22:34 AM
> Subject: Re: [edk2] OVMF.fd and placement of EfiBootServicesData
> 
> On 10/04/16 18:39, spam collector wrote:
> 
> > [...] I was surprised to see that QEMU and/or
> > OVMF requires the NvVars file to exist on the partition, else OVMF
> > does not even show the shell, even on a perfectly valid partitioned
> > image.  I don't know if this is QEMU's fault or OVMF's fault.  If
> > the NvVars file does not exist, is it the desired option to fail
> > the loading of the shell? If the file does not exist, can OVMF use
> > default values and still load the shell?
> 
> OVMF does not require the NvVars file to exist. The NvVars file is only
> used / relied on when the QEMU command line is incorrect, that is, when
> it does not configure the pflash chip(s) for storing the firmware binary
> and/or the variable store.
> 
> * The command line that you are likely used to goes like this:
> 
>   qemu-system-x86_64 -bios OVMF.fd ...

Yes.  I am currently using that line with the only modification of 
the 32-bit emulation on both parts.
 
> This is broken. Don't use it. The OVMF.fd file in the above usage is a
> unified file (1MB or 2MB in size), containing both the firmware binary
> and an empty (pre-formatted) variable store. The entire file is mapped
> into guest memory as ROM. The variable store area is not writeable,
> hence OVMF falls back to the NvVars based emulation. That emulation is
> not entirely compatible with the UEFI spec. Don't use the above command
> line.
> 
> * The first stage improvement is the following command line:
> 
>   qemu-system-x86_64 -pflash OVMF.fd

This did not work either with or without the NvVars file present.
 
> The OVMF.fd file has the same characteristics as above, but the same
> stuff is mapped as a programmable pflash chip into guest memory. It
> means that the guest memory area in question *normally* reads and
> executes like normal RAM, but if you write to it (that is, if OVMF's
> flash driver writes to it), it is flipped into "programming mode", where
> you can read and write the device using various "commands". One of those
> commands flips the device back to "normal" mode.
> 
> In this mode, the NvVars-based emulation is not used, and the variable
> store / variable services will work as defined by the UEFI spec.
> 
> The problem with this approach is that the OVMF.fd file contains both a
> firmware binary and a live variable store. You cannot upgrade the
> firmware binary without losing the VM's long-term, non-volatile variables.
> 
> * The second stage improvement is the following command line:
> 
>   # create the virtual machine's private variable store from the
>   # pristine variable store template, if the former doesn't exist yet,
>   # or has been lost for some reason
>   if ! [ -e GUEST_1_VARS.fd ]; then
>     cp OVMF_VARS.fd GUEST_1_VARS.fd
>   fi
> 
>   qemu-system-x86_64 \
>     -drive if=pflash,format=raw,unit=0,readonly,file=OVMF_CODE.fd \
>     -drive if=pflash,format=raw,unit=1,file=GUEST_1_VARS.fd \
>     ...
> 
> In this case, the OVMF_CODE.fd and OVMF_VARS.fd are used separately.
> (You can find both files under the Build directory; plus Gerd Hoffmann's
> RPM files <https://www.kraxel.org/repos/> also package them.)

For the life of me I could not find any directory called "Build".  I
did find a few RPM files and one of them contained:
  OVMF_CODE-pure-efi.fd
 and
  OVMF_VARS-pure-efi.fd
However, no matter the emulation (32- or 64-bit), neither worked and
would get as far as printing the '.' just before the 
  .FLOPPY failed
  .CD-ROM failed
  etc.
lines and go no further.
 
Thank you for the excellent description, however sorry for my
ignorance. If you don't mind, would you please specify a specific
URL that contains the two files you speak of, whether it be a listing
of those files, a .gz file, or even a .rpm file.

Thank you,
Ben