Re: OVMF.fd and placement of EfiBootServicesData

[Laszlo Ersek <lersek@redhat.com>]

On 10/06/16 05:05, spam collector wrote:
> ----- Original Message -----
>> From: "Laszlo Ersek" <lersek@redhat.com>
>> To: "spam collector" <spamcollector@cableone.net>
>> Cc: edk2-devel@ml01.01.org
>> Sent: Wednesday, October 5, 2016 8:28:46 AM
>> Subject: Re: [edk2] OVMF.fd and placement of EfiBootServicesData
>>
>> On 10/05/16 04:47, spam collector wrote:
>>>
>>> ----- 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
>>
>>>> * 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.
>>
>> I think I'll need a more complete issue riport then -- what is your
>> exact QEMU command line, and what OVMF binary are you using?
> 
> "..\qemu-system-i386w.exe" -m 256 -localtime 
>   -drive file=uefi.bin.vhd,format=raw,if=ide,media=disk,index=0 
>   -pflash ..\OVMF.fd -parallel file:para.txt
> 
> Remember that I am running this in WinXPSP3.

First, I can't "remember" it, because this is the first time you state
that. :)

Second, WinXPSP3 as host machine, really?... :)

Anyway, if both your QEMU and OVMF builds are okay / fresh enough, using
OVMF with TCG (i.e., not KVM) should work, yes.

> Also, the version of
> OVMF.fd is from http://www.tianocore.org/ovmf/ and I just noticed
> that that page has been recently changed.

That's a coincidence, but not a random one. Users have been repeatedly
confused by the r15214 binary, which at this point was more than 2.5
years old. Just before your query, I noticed
<https://bugs.launchpad.net/qemu/+bug/1622582> (and marked it invalid);
the reporter of that issue was also tripped up by the ancient r15214
build. So I asked Jordan to please update the page you reference, with a
link to Gerd's RPMs, which are bleeding edge builds.

> You use to be able to 
> download the OVMF.fd directly from that page.  It was r15214, which 
> I found out yesterday, is an older version.
> 
>>>  I did find a few RPM files and one of them contained:
>>>   OVMF_CODE-pure-efi.fd
>>>  and
>>>   OVMF_VARS-pure-efi.fd
>>
>> Yes, they are from Gerd's "edk2.git-ovmf-ia32" package (since you
>> mention IA32), from <http://www.kraxel.org/repos/>, and they are
>> recommended to use.
> 
> I also could not get these to work.  I will do a little more 
> research into why not and be sure to let you know.
> 
>> Otherwise, download the "edk2.git-ovmf-ia32" or "edk2.git-ovmf-x64" RPM
>> file (as needed) from <https://www.kraxel.org/repos/jenkins/edk2/>, and
>> extract it with:
>>
>>   rpm2cpio FILENAME | pax -r -v
>>
>> The extracted files you want are:
>>
>>   usr/share/edk2.git/ovmf-*/OVMF_CODE-pure-efi.fd
>>   usr/share/edk2.git/ovmf-*/OVMF_VARS-pure-efi.fd
>>   usr/share/edk2.git/ovmf-*/UefiShell.iso
> 
> These are the three files I used and could not get the shell to load.
> I will try a few other things and get back with you.
> 
> Please note that I am using the Windows port of QEMU from 
> https://qemu.weilnetz.de/ on a WinXP host, if that makes any 
> difference.

It could make a difference. I've never ever used Windows binaries of
QEMU. OTOH several people on this list have used such with success, so I
can't say definitely either way.

> 
> Also, one more question.  I can make my GPT image either have a legacy
> MBR with two entries pointing to one partition each or I can have a
> Protected MBR that encompasses the whole GPT, both partitions, and the
> backup items.
> 
> With the r15214 version and:
> 
> "..\qemu-system-i386w.exe" -m 256 -localtime 
>   -drive file=uefi.bin.vhd,format=raw,if=ide,media=disk,index=0 
>   -bios ..\OVMF.fd -parallel file:para.txt
> 
> it would boot to the shell either way and load and run my BOOT.efi file
> just fine, whether I had a Legacy MBR or a PMBR.  Does this make a
> difference with the new image(s) you mention above.

Sorry, I don't have any particular expertise with GPT. I believe the
PartitionDxe driver that's built into OVMF received some updates over
that 2.5y interval that I mentioned above.

> Also, please note that the hard drive image is a VHD image, a
> raw image with a single sector at the end for the VHD info so that
> Oracles VM Box will boot it.  This means that the backup GPT header
> is *not* the last sector of the disk.

As far as I know, QEMU supports VHDX. However, you pass a VHD image to
-drive with format=raw. That looks very broken. I guess I'd suggest
matching the actual image format with the format=... property. If you
pass format=raw, the VHD metadata at the end of the image will be
visible to the guest (as garbage).

>  The
> 
>   -bios OVMF.fd
> 
> version boots it just fine in QEMU, but I thought I would mention
> this in case the new code expects it to be in the last sector.

I'm quite certain all GPT drivers in the guest expect a valid disk
image, and format=raw, on a VHD disk image, seems to break that.

Laszlo